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PREFACE 


This  Note  is  one  of  five  documents  that  collectively  describe  the 
AURA  computer  model,  which  can  be  used  to  assess  the  effect  of  resources 
on  the  mission-generation  capabilities  of  combined  arms  units.  AURA  is 
an  adaptation  of  the  TSAR  model  developed  by  D.  E.  Emerson  at  The  Rand 
Corporation  under  Project  AIR  FORCE  sponsorship.  This  adaptation  was 
carried  out  under  a  project  for  the  Assistant  Secretary  of  Defense 
(Manpower,  Reserve  Affairs  and  Logistics)  entitled  "Relating  Resources 
to  the  Readiness  and  Sustainability  of  Army  Units." 

The  Army  Unit  Readiness/Sustainability  Assessor  (AURA)  model 
provides  an  analytic  context  within  which  a  variety  of  support 
improvements  may  be  tested.  Alternative  maintenance  and  supply 
doctrines,  manpower  policies,  improved  battle  damage  and  recovery 
capabilities,  and  increased  stock  levels  for  parts  and  equipment,  as 
well  as  concepts  for  improved  theater-wide  resource  management,  can  be 
examined  for  their  effect  on  mission  generation. 

The  present  Note  provides  a  full  description  of  the  input  data'  to 
be  used  in  the  AURA  model,  as  well  as  a  simplified  problem  involving  a 
hypothetical  Army  vehicle.  Companion  Rand  documents  relating  to  AURA 
and  AURA-compatible  models  include: 

•  R-2769-MRAL,  Relating  Resources  to  the  Readiness  and 
Sustainabil ity  of  Combined  Arms  Units,  December  1981. 

•  N-1460-AF,  TSARINA:  User's  Guide  to  a  Computer  Model  for 
Damage  Assessment  of  Complex  Airbase  Targets ,  July  1980. 

•  N-1987-MRAL,  AURA  User's  Manual:  Vol .  I,  Program  Features 
and  Interactions,  June  1983. 

•  N-1999-MRAL,  AURA  Applications:  Division- Level  Transportation 
and  Selected  Spares  Issues ,  forthcoming. 
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ABSTRACT 


_ AURA  (Army  Unit  Readiness/Sustainability  Assessor)  is  a  Monte  Carlo 
discrete-eventy(simulation  model  intended  for  analyzing  the 
interrelations  among  the  resources  associated  with  a  set  of  combat 
units,  and  the  capability  of  those  units  to  generate  combat  missions  in 
a  dynamic,  rapidly  evolving  wartime  environment. 

This  volume  is  the  second  of  two  being  prepared  as  a  User’s  Manual 
for  AURA.  It  discusses  the  input  requirements,  procedures,  and  formats, 
and  provides  a  sample  problem  based  on  a  hypothetical  Army  combat 
vehicle.  These  detailed  discussions  provide  the  only  complete 
explanations  for  some  of  the  numerous  control  options  available  with 
AURA  and  must  be  considered  mandatory  reading  for  potential  AURA  users. 
The  sample  problem  illustrates  an  AURA  data  base  and  the  various  ouputs 

available  with  AURA.  Volume  I  of  this  series  describes  the  capabilities 

rr 

and  processing  logic  of  the  model. 
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XVI.  INTRODUCTION 


Volume  II  of  the  User's  Manual  is  intended  primarily  for  those 
responsible  for  preparing  input  materials  and  for  operating  the  AURA 
computer  simulation  model. 

AURA  is  a  Monte  Carlo  discrete-event  simulation  model  intended  for 
analyzing  the  interrelations  among  the  resources  associated  with  a  set 
of  combat  units,  and  the  capability  of  those  units  to  generate  combat 
missions  in  a  dynamic,  rapidly  evolving  wartime  environment.  On-vehicle 
maintenance  tasks,  parts  and  support  equipment  repair  jobs,  munitions 
assembly  jobs,  and  facilities  repair  tasks  can  be  simulated  for  each  of 
up  to  63  operating  units,  as  well  as  intratheater  transportation, 
communication,  and  resource  management.  Asset  accounting  for  each  of  11 
classes  of  resources,  and  for  each  type  within  each  class,  permits 
assessment  of  a  broad  range  of  policy  options  that  could  improve  the 
efficiency  of  resource  utilization  on  a  corps  or  theater-wide  basis. 

An  important  objective  in  the  original  design  formulation  of  TSAR, 
AURA's  parent  model,  was  to  achieve  a  sufficiently  high  speed  of 
operation  that  the  extensive  (often  trial  and  error)  sequence  of  runs  so 
frequently  necessary  in  research  and  analysis  would  be  economically 
practical.1  Adaptation  of  existing  models  (e.g. ,  LCOM,  SAMSOM)  was 
rejected  for  several  reasons,  including  the  extent  of  the  modifications 
that  would  have  been  required  and  the  prohibitive  costs  that  would  be 
associated  with  their  use  for  problems  of  the  size  that  were 
contemplated.  The  initial  phase  of  development  was  designed  to  test  the 
hypothesis  that  speed  would  be  improved  if  custom-tailored  list 
processing  techniques  were  created  using  the  widely  available  FORTRAN 
language,  rather  than  using  standard  simulation  language  packages,  and 
if  full  advantage  were  taken  of  the  large  amounts  of  directly  accessible 
computer  memory  that  are  now  available.  The  resultant  custom-designed 
TSAR/AURA  program  achieves  a  substantially  higher  speed  than  previously 
developed  simulation  models  of  equivalent  and  lesser  complexity. 

1  At  present,  the  TSAR  and  AURA  source  codes  are  virtually  the 
same,  though  certain  program  dimensions  are  different,  and  all  output 
formats  in  AURA  use  terminology  more  familiar  to  Army  personnel. 
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In  its  current  formulation,  AURA  makes  no  intermediate  use  of 
auxiliary  high-speed  storage  units  (e.g.,  disks,  tapes)  except  for 
storing  the  initial  conditions  for  multiple  trials.  To  constrain  the 
substantial  computer  storage  requirements  generated  by  this  design 
feature,  all  but  a  handful  of  the  program  variables  and  array  elements 
occupy  only  two  bytes  of  core,  and  many  of  the  array  elements  are  packed 
with  two  and  sometimes  three,  four,  or  even  five  pieces  of  information. 

AURA  now  consists  of  126  subroutines  and  8  functions  (with  225 
entry  locations);  the  source  code  consists  of  over  40,0r0  card  images, 
exclusive  of  that  required  for  the  common  statements.  Without  the  space 
required  for  the  data  storage  arrays,  approximately  500K  bytes  are 
required  for  the  program,  when  the  input-related  subroutines  are 
overlaid.  If  certain  features  are  not  to  be  used  (e.g.,  enemy 
air/artillery  attack,  corps  or  theater  management  of  vehicles  or  other 
resources,  and  parts  initialization)  this  requirement  can  be  reduced  by 
overlaying  the  subroutines  associated  with  the  unused  features.  Useful 
applications  of  AURA  involving  an  entire  combined  arms  brigade  may 
require  1000K  bytes  for  data  storage,  but  other  applications  may  require 
only  50  to  100K  bytes  for  storage.  The  auxiliary  SIZE . AURA . STORAGE 
program  quickly  estimates  the  user's  requirements.  All  data  that  would 
be  needed  to  resume  operation  in  the  event  that  processing  was 
interrupted  (as  might  be  done,  for  example,  if  one  wished  to  adapt  the 
program  for  interactive  operation)  are  in  COMMON  statements. 

OUTLINE  OF  MATERIALS 

The  materials  in  this  volume  and  the  extensive  comments  included  in 
the  AURA  source  code  are  designed  to  help  those  responsible  for 
preparing  input  materials  and  for  operating  AURA.  The  next  section 
outlines  the  classes  of  resources  that  AURA  can  deal  with,  and  discusses 
certain  built-in  numerical  constraints  that  the  user  must  observe. 
Section  XVIII  outlines  the  procedures  that  are  to  be  used  in 
restructuring  AURA  storage  space  for  each  user's  special  requirements. 
Since  essentially  all  data  are  retained  in  core  during  execution,  core 
management  discipline  will  dictate  occasional  program  redimensioning, 
when  the  character  of  the  situation  to  be  simulated  changes  greatly. 


Section  XIX  is  the  key  source  of  information  for  the  use  of  AURA; 
it  is  the  only  location  in  which  all  of  AURA's  features  and  controls  are 
explained.  Section  XIX  provides  extensive  discussions  and  explanations 
of  the  appropriate  data  entry  procedures  for  the  50-plus  data  entry 
formats  that  are  used  with  AURA.  Each  discussion  presents  a  copy  of  the 
data  input  format  and  sample  entries  to  illustrate  the  use  of  each  form. 
When  options  exisv,  each  is  illustrated.  Section  XX  describes  a  sample 
data  base  for  a  single  hypothetical  Army  combat  vehicle. 

DATA  REQUIREMENTS 

AURA  input  data  requirements  naturally  depend  upon  the  level  of 
detail  at  which  the  simulation  is  to  be  conducted  and  the  features  that 
are  to  be  used.  Many  sources  are  available  that  can  contribute  to  these 
requirements.  Of  the  different  types  of  data,  probably  the  most  complex 
and  difficult  to  obtain  are  those  that  define  the  demands  and  resources 
for  unscheduled  maintenance  and  parts  repair  for  different  types  of 
vehicles.  Fortunately  many  of  these  data  are  collected  on  a  regular 
basis  for  various  purposes  by  the  Army,  including  initial  spare  parts 
provisioning  and  manpower  authorization  studies.  A  companion  document 
to  be  issued  in  the  near  future  will  illustrate  how  such  data  can  be 
extracted  from  Contingency  Maintenance  Allocation  Charts  (CMACs)  for 
combat  and  tactical  vehicles. 
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XVII.  RESOURCE  LIMITATIONS 


Eleven  distinct  classes  of  resources  may  be  monitored  using  AURA, 
but  only  vehicles  are  mandatory.  The  11  classes  of  resources,  the 
number  used  to  identify  each  class,  the  arrays  in  which  their  status  is 
stored,  and  the  restrictions  on  the  numbers  of  types  and  the  numbers  of 
each  type  are: 


Resource  Class 

Name  Number 

Storage 

Array 

Maximum 
Number  of 
Types 

Number 

Per  Type 
Per  Unit 

Maximum 
Number 
Shipped 
Per  Lot 

Vehicles 

8 

ACN 

9 

999 

250 

Crewmen 

PILOT 

1  per  veh.  type 

-- 

250 

Shelters 

BASES 

1  per  unit 

999 

-- 

Ma intenance 

1 

PEOPLE 

320 

320 

250 

personne 1 

Support  equipment 

2 

AGESTK 

99 

127 

250 

Parts  (LRU,  SRU) 

3 

PARTS 

3199 

320 

250 

250 

Munit ions 
(assembled  and 

4 

MUNSTK 

99 

32000 

6250 

6250 

unassembled) 

Accessories 

5 

TRAP 

99 

32000 

6250 

Building  materials  6 

MATERL 

99 

32000 

250 

POL  7 

POLSTK 

1 

32000 

250  x  (10 

Other  facilities  9 

FACLTY 

250 

1 

Vehicles,  crewmen,  facilities,  and  reparable  spare  parts  are 
monitored  on  an  individual  basis;  all  others  are  handled  in  more 
aggregated  terms.  The  level  of  detail  varies  from  that  maintained  for  a 
vehicle--potentially  several  dozens  of  items  of  in format ion --down  to  a 
simple  tally  of  the  numbers  of  shelters  and  the  amount  of  POL  available 
at  each  unit. 


Although  not  explicitly  treated  as  a  resource  (except  insofar  as 
physical  damage  thereto  may  be  reflected  in  the  FACLTY  array),  the  work- 
centers,  or  shops,  in  each  unit  are  the  entities  around  which  vehicle 
maintenance  activities  and  the  parts  and  support  equipment  repair 
activities  are  organized.  Except  for  combat  engineer  resources,  all 
ongoing,  interrupted,  and  waiting  jobs  are  locatable  using  the  pointers 
stored  in  the  SHOPS  array;  that  array  stores  26  data  elements  for  each 
shop  on  each  unit.  AURA  storage  arrays  are  sized  for  a  maximum  of  30 
shops,  the  last  five  of  which  are  reserved  for  premission  tasks  and 
weapons  assembly  jobs. 

The  subroutines  that  prepare  resources  for  intratheater  shipment 
(SHPRES)  and  that  receive  intertheater  and  intratheater  shipments 
(DOSHIP)  are  written  to  accommodate  maintenance  personnel,  support 
equipment,  parts,  munitions,  accessories,  building  materials,  and  POL. 
However,  the  only  theater  resources  that  are  actually  transferred  within 
the  theater  using  the  current  theater  management  logic  are  maintenance 
personnel,  support  equipment,  and  parts;  all  resources  may  be  received 
from  CONUS.  Similarly,  the  program  logic  permits  vehicles  and  spare 
crewmen  to  be  moved  to  the  theater  from  CONUS,  and  allows  vehicles  to  be 
moved  from  one  unit  to  another  within  the  theater  for  maintenance  and  to 
be  directed  to  return  to  a  different  unit  than  the  one  from  which  they 
were  last  sent  on  a  combat  mission. 


XVIII.  DIMENSIONING  AND  REDIMENSIONING 


For  many  study  applications  it  will  be  appropriate  and  necessary  to 
redimension  various  portions  of  AURA's  data  storage  arrays.  All  the 
arrays  are  listed  below,  and  their  dimensions  are  defined  in  terms  of 
variables  that  are  in  COMMON.  When  the  user's  data  demands  a  different 
amount  of  space  for  storage,  or  if  the  problem  can  be  projected  to 
require  a  substantially  different  amount  of  space  for  queuing  the 
internally  generated  event  data  (e.g.,  tasks  in  process,  interrupted, 
and  waiting),  the  dimension  can  be  changed  in  all  necessary  locations 
with  a  single  text  editor  command. 

A  special  auxiliary  program  called  SIZE. AURA. STORAGE  has  been 
written  to  facilitate  the  necessary  preparatory  steps  for  redimensioning 
AURA.  All  storage  arrays  are  located  in  one  of  25  different  COMMON 
statements ,  and  these  statements  are  inserted  into  the  appropriate 
subroutines  by  referring  to  their  individual  locations  in  storage;  by 
this  means,  only  one  change  is  required  to  redimension  any  given  array 
in  all  the  locations  in  which  it  ultimately  appears.  This  process  is 
outlined  in  detail  in  the  comments  in  the  INIT  subroutine,  and  in  the 
SIZE. AURA. STORAGE  program. 

The  dimensions  of  all  arrays  in  all  COMMON  statements  are  shown  in 
the  list  below  using  the  variable  that  the  program  associates  with  each 
dimension.  The  appropriate  value  for  many  of  the  array  dimensions  will 
be  uniquely  identifiable  by  the  nature  and  data  of  the  user's  problem. 
However,  the  dimensions  needed  for  the  data  generated  dynamically  during 
the  simulation  are  not  knowable,  a  priori.  Some  experience  with  the 
particular  application  will  be  needed  if  space  is  to  be  conserved  and 
data  (tasks,  jobs,  shipments,  etc.)  are  not  to  be  lost;  OVERFL  permits 
the  user  some  flexibility  for  dealing  with  this  problem.  The  temporary 
queues  in  subroutine  DELAYS  may  also  overflow,  but  a  warning  to  that 
effect  is  printed.  Arrays  with  deterministic  requirements  are  in  the 
first  of  the  following  lists;  the  queues  and  heaps  are  listed  second. 
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Many  of  the  arrays  are  dimensioned  by  MAXM,  MAXT,  and  MAXB--i.e. 
the  maximum  numbers  of  missions  per  vehicle  type,  vehicle  types,  and 
units.  These  dimensions  are  abbreviated  here  as  M,  T,  and  B.  The 
limits  for  these  dimensions  are  5,  9,  and  63. 
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DETERMINISTIC  DIMENSION  REQUIREMENTS 


ACA(3,M,T,B) 
ACMDTA(20 ,M,T) 
ADELAY(24 ,2 ,B) 
AGERPT(NOAGE , 8 ) 
AGESTK (NOAGE , 3 ,B) 
AISDTA(NOSTAT , 5 ) 

ALERT(6,M,T,B) 

ALTPEO (NOPEOP , 3 ) 
ATTACK (LTHATT, 5) 
AVGREP(25,T) 
AVGTSK(25,T) 

BORROW (NOUSER, 2) 
BSOR(B) 

CANFLY(3,M,T,B) 
CARGO (NC ARGO, 2) 
CERQTS ( 8 , NOCE ) 
CIRFTM(24) 

CONF I G ( NOCONF , 8 ) 
COSTS (NOPART) 

CTPEO (NOPEOP) 
DAMAGE (NO ITEM, 2) 
DEPOT2 (NOAGE) 
DEP0T4 (NOMUN) 
DEPOT6 (NOMATL) 
FACDAM (NOFAC ,6) 
FILLER(T,2) 

FRACJB (NOFAC) 
INPIPE (NOPART, B ,2) 
HURRY (B , 5 , 2 ) 
JOBDTA(20 , 2) 
LANDNG(B) 
LISTIN(LTHLST) 
MAXOFF ( 2 , T ) 
MUNRQT(4 ,NOBILD) 
NOR(B) 

NSTAT (NOSTAT , 2 , B ) 
OFFCOB (NOPART, T) 
OUTAGE (2, NOAGE, B) 
OUTMAT( 2, NOMATL, B) 
OUTPER ( 2 , NOPEOP , B ) 
OUTPRT (2, NOPART, B) 
OUTTRP( 2, NOSTAB, B) 
OUTPT2 (3 , 3 , 25 , B) 
0(JTP'i'4  ( 2 , 30  ,  M ,  B  ) 
PARTRQ( NOPART, T) 
PEOPLE (NOPEOP, 7, B) 
PEORQT (NOPEOP, M,T) 
PI LOT (5, NOCREW) 


ACDATA(25,T) 
ACN(MAXACN,40) 
AGEREP (NOAGER , 6 ) 
AGERQT ( NOAGE , M , T) 
AIDALT(T) 

AISUSE (NOSTAT, 5 ,B) 
ALT AGE (NOAGE, 3) 
AQPEOP (NOPEOP, 5) 
AVGP(3 , 30 , B) 
AVGSHP(B) 

BASES (50 , B ) 

BPARTS( 15 ,T,B) 
CANCEL(5 ,T,B) 
CANNTM (NOPART) 
CEPRTY (NOFAC) 
CHCKED (NOPART) 
CKFILL(T) 

CONUS (NOCONS , 2 ) 

C STOCK (NOPART, 2) 
CTPEOP (NOPEOP, 5) 
DEPOT1 (NOPEOP) 
DEPOT3 (NOPART) 
DEPOT5 (NOSTAB) 
DEPOT8 (T) 

FACLTY ( 6 , NOFAC , B ) 
FRACB  S ( NOPART , B ) 
GTLMT( NOPART) 

I P I PE ( NOPART , 2 ) 
ITEMS (B) 

JOBPR(2,T) 

LATERL(B) 

MATERL (NOMATL, B) 
MUNRQD( NOMUN, M,T) 
MUNSTK ( NOMUN , 4 , B ) 
NORHRS(B) 

OFFBSE(2 ,50 ,2 ,T) 
OFFMOB (NOPART, T) 
OUTFAC ( 2 , NOFAC , B ) 
OUTMUN ( 2 , NOMUN , B ) 
OUTPOL ( 2 , B ) 
0UTSHP(6 , 30 ,B) 
OUTPT 1(5,6,M,T,B) 
0UTPT3 ( 2 , M , T , B ) 
OUTPT5(5 ,30,B) 
PARTS (NOPART, 5, B) 
PEOR PT( 2, NOPEOP, B) 
PERI0D(20 ,3) 

P I  LOTS ( 5 , T , B ) 
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POLICY (NOPART , B , 2 ) 
+PRTCRT ( NOPRT , 2 ) 
PRTRPT (4, NOPART, B) 
PTZ(M,T,B) 

REDUCE(B ,5,2) 
RELIMP(33 ,5) 
REPORT(NOREPT , 4 ) 
RINDEX(4,9) 

SAVE (B, 5 ,2) 
SCLRQT(NOSCL, 9 ) 
SEEDS (10) 

SHIPSC (NOSHP ,3) 
SHIPTO(B ,20,2) 
SHOPEO (NOPEOP) 
SHOPS (26 , 30 , B) 
SHPORD(50,T,B) 
SHPTSK ( 3 , NOTASK , 25 
SORCAP(T.B) 
SORTHR(24,B) 
SRFRAC(B ,2) 
START(6) 

SVEFLT( 12,5) 

TEMPF (50 ,4) 

TOC I RF( NOPART, 2) 

TP ART ( EXTPRT , 3 , B ) 
STABRQ(2 , 3 ,T) 

TRAYS (NOTRAY) 
TRYFLY(6,T,B) 
TSKCRT(99 , 5 ) 
TSKRQT(NOTSK, 15) 
XMIT(4,B) 

ZTASKSC5 ,T,B) 

+NOPRT  must  at  least  equal  the 


DYNAMIC  DIMENSION 


POLSTK(B) 

+PRTLST (NOPRT) 

PRTRQ ( NOPART, 2, T) 
RECORD (NSCROL , 3 , MAXREC ) 
REFILL(2 ,9) 

REPALT (NOREPA , 4 ) 
REPRQT(NOREP,8) 

ROOTS ( NOPART, T) 

SCLP(5 ,M,T,2) 

SEEDED (10) 

SHIP(NOSHIP, 7 ) 

SHIPTM(B , B , 3) 

SHOPAG( NOAGE) 

SH0PRQ(30,M,T) 

SHORT(NOPART) 

SHPT(B ,B ,4) 

T)  SICK(NOPEOP) 

SORDEF( 16 , 3 ,M,T,B) 

SPARE (2 ,M,T,B) 

STAFF (NOPEOP, 2) 

STOP (6) 

TCONF(M,M,T) 

THDATA(4 ,3) 

TOTALS (NOPART, B, 3) 

STAB (NOSTAB, 8) 

TRAY (NOPART) 

TRAYST( NOTRAY , 2 , B ) 
TSKALT (NOTSKA , 5 ) 
TSKPR(25,T,3) 
WXDATA(WXDAYS , 2 , B) 

Z PRTRQ (NOPART) 


highest  part  or  LRU  number. 


REQUIREMENTS 


Queues  and  Heaps 


BACKLG(5 ,LLQ) 
CEJ0BQ(LTHCEQ,9) 
DEFTSK ( LDT , 4 ) 
INTTSK(L1Q, 10) 
NORQ(NNOR ,3) 

RE JOIN (N JOINT, 2) 
REPQ(LRQ.ll) 
RQDTSK ( LNT , 2 ) 
TASKQ(LTQ, 16) 


BUILDQ(LBQ.IO) 
CHANGE (NOCHG , 5 ) 
FLTRQT(LFQ.IO) 
LIMBO (NLIMBO , 6 ) 
PRDFLT (MAXPER , 5 ) 

RESUPP(LGQ,5) 
SHIPQ(NOPKG,3) 
WAITSK(LWQ, 13) 
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XIX.  DATA  ENTRY 


The  data  requirements  for  AURA  are  substantial,  and  it  is  mandatory 
that  the  user  observe  the  specifications  outlined  here.  Even  though 
AURA  checks  input  data  for  a  considerable  number  of  possible  errors, 
possibilities  for  error  remain  and  great  care  should  be  exercised  with 
data  entry.  Careful  adherence  to  the  data-entry-form  specifications  is 
advised . 

Data  entry  is  accomplished  using  the  (approximately)  50  distinct 
card  formats  illustrated  in  this  section.  With  few  exceptions  (to  be 
outlined)  all  cards  are  read  with  the  same  format  (12,13,1515)  and  all 
data  must  be  right-adjusted.  The  number  of  the  Card  Type  appears  in  the 
first  two-column  field.  The  second  field  (cols.  3-5)  is  occasionally 
referred  to  as  the  "j"  field.  Although  there  are  only  a  few  constraints 
on  the  actual  order  in  which  the  cards  are  arranged,  data  organization 
will  generally  be  simplified  and  fewer  errors  incurred  if  the  various 
card  types  are  entered  in  numerical  order. 

The  proper  organization  of  a  card  deck  of  AURA  input  data  is 
illustrated  in  Fig.  1.  As  will  be  noted,  several  special  control  cards 
are  needed,  in  addition  to  the  formatted  input  data  cards.  The  first 
input  card  controls  which  of  the  numbered  input  cards  are  to  be  listed 
as  a  part  of  the  printed  record  of  the  job.  That  card  is  followed  by 
Card  Types  #1  through  #4,  including  whatever  comment  cards  the  user  has 
added  after  Card  Type  #1;  these  cards  define  the  user's  selection  of  the 
primary  control  data,  as  will  be  described  shortly.  Descriptions  of  the 
various  kinds  of  jobs,  the  quantities  of  resources  available  at  each  of 
the  operating  units,  specifications  for  the  transportation  and 
communications  systems,  etc.  are  entered  next  using  Card  Types  #5 
through  #49.  The  end  of  this  large  set  of  input  cards  is  designated 
with  a  Type  #99  Card;  and  following  that  is  another  special  card  that 
controls  which,  if  any,  of  the  initialized  contents  of  the  data  storage 
arrays  are  to  be  listed  in  the  printed  record  of  the  job. 
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The  mission  demand  data  (Type  #50  Cards)  and  any  transportation 
schedule  changes  (Type  #60  Cards)  conclude  the  input  data  deck.  These 
cards  may  be  arranged  in  several  groups  that  are  to  be  read  at  different 
times  during  the  simulation;  the  last  of  the  first  group  of  such  cards 
is  denoted  by  another  Type  #99  Card  that  specifies  (in  the  "j"  field) 
the  day  of  the  simulation  when  the  next  group  of  mission  demand  data  are 
to  be  read.  As  noted  in  Fig.  1,  each  subsequent  group  of  mission  demand 
data  cards  is  also  terminated  with  a  Type  #99  Card  and  each  of  these 
cards  must  specify  how  many  simulated  days  are  to  elapse  before 
additional  mission  demand  data  should  be  input. 

Most  data  for  AURA  are  stored  as  half-words  (two-byte  integers), 
and  many  of  the  half-words  are  packed  with  2,  3,  4,  or  5  pieces  of  data. 
Since  AURA  was  designed  to  be  compatible  with  a  32-bit-word  machine 
(e.g.,  IBM),  the  largest  integer  that  may  be  stored  in  a  half  word  is 
215  -  1.  The  number  32750  is  occasionally  used  in  the  code  to  denote 
"infinity"  and  the  user  must  exercise  care  that  no  larger  number  is 
entered  in  any  of  the  five-column  fields.  (When  50,000  units  of  fuel 
were  inadvertently  provided  a  unit  in  an  early  test  run,  the  quantity 
was  recorded  as  negative,  and  all  missions  were  canceled.) 

One  consequence  of  these  data  storage  features  is  that  time  is 
subdivided  into  three-minute  increments  referred  to  as  TTU- -TSAR (AURA) 
time  units--and  the  maximum  length  of  time  that  should  be  simulated  per 
trial  is  65  days;  to  generate  a  single  history  of  greater  length,  it  is 
necessary  to  use  the  EXTEND  feature  (see  Card  Type  #1). 

The  Card  Type  descriptions  that  follow  each  include  (a)  the  entry 
form  formats,1  (b)  a  description  of  the  nature  of  the  data  requirements, 
and  (c)  comments  on  the  occasional  nonstandard  formats.  As  will  be 
noted  in  many  places  on  the  card  formats,  the  data  are  sometimes  packed 
automatically  on  input--i.e.,  when  two  or  more  data  items  are  read  in 
the  same  five-column  field. 

Although  AURA  will  be  compatible  with  machines  that  use  more  than 
32  bits  for  a  word,  it  will  not  function  properly  on  a  machine  that  uses 
a  shorter  word.  For  those  installations  at  which  half-words  (integer*2) 

1  Master  copies  of  these  entry  forms  will  be  made  available  to 
those  who  obtain  a  tape  copy  of  the  AURA  program. 


are  not  available,  data  storage  requirements  will  be  nearly  doubled,  but 
no  difficulties  should  be  encountered  with  the  "packed"  data. 

Each  of  the  shops  and  each  of  the  sets  of  resource  requirements 
(e.g.,  tasks,  repairs,  combat  loadings,  and  their  alternatives),  as  well 
as  each  of  the  various  types  of  the  various  resources,  are  identified 
within  the  model  by  a  number.  That  number  also  designates  the  column  of 
an  array  in  which  the  data  regarding  that  entity  are  stored.  The  user 
must : 

•  Name  each  such  element  that  is  involved  in  his  problem  with  a 
number , 

•  Assure  that  that  number  is  no  greater  than  the  size  of  the 
storage  array  for  that  class  of  information  and  that  only  one 
member  of  that  class  has  that  number, 

•  Maintain  lists  (dictionaries)  of  such  definitions,  external  to 
the  program,  to  avoid  confusion, 

•  Assure  the  accuracy  of  all  cross-references  within  the  input 
data  that  involve  these  user-specified  entity  names. 

AURA  PRIMARY  CONTROL  DATA 

Card  Types  #1  through  #4,  shown  in  Fig.  2,  provide  for  entry  of  key 
AURA  control  variables.  These  cards  should  be  at  the  beginning  of  the 
user's  card  deck  and  should  be  entered  in  numerical  order.  All  data 
must  be  right-adjusted.  The  many  control  variables  that  the  user  sets 
with  Card  Types  #1  through  #4  either  define  operating  conditions  for  the 
simulation,  activate  (or  deactivate)  AURA's  optional  features,  or 
delineate  the  user's  choice  among  optional  operating  modes. 

Two  special  convenience  features  may  be  invoked  with  Card  Types  #1 
and  #2/1.  If  the  user  desires  to  have  his  output  headed  by  N  lines  of 
descriptive  material,  the  number  N  is  entered  in  columns  3-5  on  Card 
Type  #1,  and  N  card  images  are  then  mandatory  before  Card  Type  # 2/1  is 
read;  there  are  no  format  restrictions  for  these  descriptive  materials. 
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The  first  control  variable  on  Card  Type  #2/1  is  TEST.  A  null  entry 
is  appropriate  for  normal  operation,  but  a  variety  of  intermediate 
debugging  data  may  be  obtained  by  initializing  this  variable.  For 
positive  entries  between  1  and  15,  an  ever  increasing  amount  of  such 
data  will  be  printed  for  all  trials.  If  the  entry  is  -1,  the  volume  of 
such  output  can  be  reduced  by  limiting  debugging  output  to  one,  or  up  to 
six,  specific  periods  of  simulated  time  during  a  specific  trial:  When 
this  is  done,  a  single  card  image  must  immediately  follow  Card  Type 
#2/1,  which  specifies  the  trial,  the  time  intervals,  and  the  value  for 
TEST  during  those  time  intervals.  This  card  is  read  as  13,  12,  1215; 
the  order  of  data  entry  is  TTRIAL,  TEST,  START ( 1 ) ,  ST0P(1),  .  .  .  , 

START(6),  ST0P(6).  If  the  trial  number  (TTRIAL)  is  not  specified,  the 
output  will  occur  during  the  first  trial.  The  times  are  to  be  entered 
in  AURA  time  units  (i.e.,  3  minute  time  intervals);  one  to  six  time 
intervals  may  be  specified  and  the  intervals  must  be  entered  in  the 
order  of  their  occurrence. 

Card  Type  #1 

If  J  is  not  zero,  J  comment  cards  must  follow  this  card 

SIMLTH  Length  in  days  of  the  period  to  be  simulated. 

NTRIAL  Number  of  repetitions  of  the  simulation. 

EXTEND  If  unity,  an  NTRIAL  simulation  produces  a  single  history 

NTRIAL  x  SIMLTH  days  in  duration. 

SEED  If  set  equal  to  a  nonnegative  integer,  the  operating 

system  selects  a  reproducible  value  for  the  SEED  of  the 
random-number  generator;  if  set  to  zero  the  SEED  is 
selected  by  a  random  process. 

NUNIT  Number  of  units  that  will  actually  operate  combat  or  tactical 

(NBASE)  vehicles  as  pacing  items  (may  be  less  than  or  as  great  as  MAXB). 

NTYPE  Number  of  vehicle  types  to  be  used  in  the  simulation 

(may  be  less  than  or  as  great  as  MAXT) . 

CREWS  Crewmen  are  accounted  for  when  =  1;  neglected  if  0. 
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BUILD 

AURA 

(TSAR) 

CMODE 

CONS  I G 

AIDA 


Switch;  when  unity,  the  munitions  assembly  features  are 
activated. 

If  unity,  resources  are  managed  centrally;  if  set  to  2 

the  highest  numbered  unit  will  act  as  a  general  support  j 

repair  facility  that  does  not  operate  vehicles  as  pacing  | 

items .  | 

f 

When  not  zero  defines  the  mode  of  operation  for  corps  or  | 

theater  resource  management  (see  Section  XI). 

If  zero,  any  parts  that  are  shipped  to  the  theater  to 
replace  condemned  parts,  and  LRUs  that  were  NRTSed  to 
CONUS,  are  consigned  to  the  unit  of  origin  on  return;  if 
unity,  all  parts  are  consigned  to  the  theater  manager  for 
distribution. 

Controls  the  interpretation  of  unit  damage  resource  data; 
normally  not  to  be  specified  by  the  user,  but  to  be  entered 
with  the  damage  data. 
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Card  Type 

TEST 

VERIFY 

PRINT 

SCROLL 

OVERFL 


STATFQ 

CUMSTA 


#2/1 


Controls  internal  debugging  features.  If  >  0,  diagnostic 
messages  are  printed  for  the  entire  simulation;  if  -1,  a 
special  card  must  follow  defining  the  time  intervals  for 
the  debug  output . 

Controls  input  data  testing  features.  If  -  1  or  2, 
limited  tests  are  made  on  input;  if  =  3,  each  input  card 
is  checked  by  subroutine  TESTER.  The  meaning  of  resulting 
error  type  numbers  can  easily  be  determined  by  reference 
to  subroutine  TESTER,  where  the  variable  "M"  (the  number 
of  the  error)  is  incremented  for  each  test  on  each  card. 

If  £  2,  operation  is  terminated  after  initialization. 

Value  controls  content  of  simulation  output  (see 
Section  XV) . 

Provides  vehicle  activity  reports  for  the  specified 
number  of  days  for  up  to  24  vehicles,  starting  with  the 
vehicle  number  specified. 

Value  controls  simulation  behavior  if  the  dimensions  of 
the  arrays  used  to  store  internally  generated  data  are 
exceeded: 

When  OVERFL  =  0,  simulation  stops; 

=  1,  overflow  noted  and  tallied; 

=  2,  overflow  noted  for  first  entry  ,'.n  ■' 
tall ied ; 

=  3,  overflow  tallied. 

This  feature  must  be  used  with  caution  because  program 
behavior  can  become  extremely  erratic  whe:.  certain  types 
of  records  are  discarded.  In  any  event  execution  is 
terminated  automatically  at  the  end  of  any  day  if  the 
cumulative  number  of  discarded  records  is  20  or  more. 

The  frequency,  in  days,  with  which  the  summary  data 
regarding  the  average  length  of  time  for  tasks  and  jobs, 
and  the  causes  and  lengths  of  the  vehicle  delays,  are 
printed.  If  STATFQ  =  0,  these  data  are  not  collected  or 
printed . 

Controls  the  cumulation  of  task  and  delay  time  data; 
when  0,  data  are  cumulated  separately  for  each  trial; 
when  1,  data  are  cumulated  across  all  trials. 


NONUNI 


When  unity,  resource  losses  are  determined  by  a  sample 
from  the  binomial  distribution;  if  zero,  losses  are 
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CEWORK 

ATRISK 

CEPEO 

CEAGE 

CRBLDG 


determined  on  a  straight  percentage,  or  expected  value  basis. 

Switch;  when  unity,  combat  engineering  resources  are 
allocated  to  repair  damage  from  enemy  air/artillery 
attacks  in  accord  with  the  priorities  defined  by  the 
CEPRTY  array. 

When  a  shop  facility,  or  all  elements  of  a  distributed 
shop,  are  damaged  at  the  time  of  a  subsequent  attack, 
the  resources  assigned  to  that  shop  are  assumed  to  have 
been  relocated  and  to  be  invulnerable  if  ATRISK  is  zero; 
if  ATRISK  is  unity,  the  damage  is  assessed  as  though 
operations  were  normal. 

The  number  of  types  of  personnel  associated  (exclusively) 
with  combat  engineering  tasks. 

The  number  of  types  of  support  equipment  associated 
exclusively  with  combat  engineering  tasks. 

Unless  combat  engineering  resources  are  sufficient  to 
initiate  repairs  to  all  damaged  facilities  up  to  and 
including  this  priority,  reconstruction  tasks  are  pursued 
with  secondary  procedures  using  lesser  resources. 
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Card  Type  #2/2 

AURA  provides  ten  distinct  random  number  streams  that  are  repeated 
from  trial  to  trial.  These  streams  can  be  disengaged  only  if  the  user 
enters  a  "-l"  in  the  Nth  field  on  Card  Type  # 2/2  to  disengage  the  Nth 
stream . 

At  this  time,  only  five  of  the  random  number  streams  are  used.  The 
first  random  number  stream  (cols.  6-10)  is  used  in  the  generation  of 
AURA’s  vehicle  mission  demands;  the  second  is  used  for  selecting  the 
intratheater  transportation  schedules;  the  third  is  for  generating 
resource  status  reports;  the  fourth  is  for  selecting  the  zero-time  shop 
activity  controlled  by  Card  Type  #42;  and  the  fifth  is  used  in 
generating  "actual"  task  probabilities  for  unscheduled  maintenance  when 
UNCER  is  not  zero.  Random  streams  six  (cols.  31-35)  through  ten  (cols. 
51-55)  currently  are  available  for  additional  applications. 


AUXILIARY  CONTROL  VARIABLES 

ADAPTR  NRTS  policy  for  RR  parts  is  changed  when  there  are  fewer 
LRUs  than  ADAPTR  percent  of  the  initial  LRU  stocks;  they 
are  shipped  to  a  lateral  resupply  unit  rather  than 
nominal  NRTS  destination  if  the  NRTS  rate  at  that  unit  is 
lower  than  at  the  unit  where  the  reparable  was  generated. 

SEEKSH  When  unity,  another  in-theater  shop  is  sought  for  parts 

repair,  when  the  nominal  shop  is  closed  by  damage;  useful 
when  simulating  several  general  support  maintenance  activities. 

SHPREP  When  not  zero,  all  parts  repaired  at  an  operating  unit  are 
shipped  to  the  unit  that  is  selected  with  the  SEND  logic 
in  the  CONTRL  subroutine,  when  (NMCS  Vehicles  - 
Required  Parts)  is  greater  than,  or  equal  to,  SHPREP. 

NRTPOL  If  unity,  an  LRU  that  requires  an  SRU  that  is  unavailable 
and  is  not  normally  stocked,  is  NRTSed. 

T0D0CK  If  unity,  parts  that  are  normally  NRTSed  to  another  unit, 
but  can't  be  because  no  shipment  schedule  exists,  are  held 
for  later  lateral  repair  rather  than  being  sent  to  CONUS. 
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Card  Type  #3/1 


OPSBSE 


POSTPN 


IGNORE 

CONCUR 


LTHDEF 


CANMOD 

MXHOLE 

DOCANN 


CANMUL 


CANSRU 


CRASH 


Number  of  units  that  may  initiate  combat  missions; 
excludes  rear  maintenance  units  and  a  general  support 
repair  facility,  if  any. 

If  zero,  all  unscheduled  maintenance  tasks  must  be 
accomplished  before  next  mission;  if  =  1,  tasks  will  be 
deferred  (postponed)  that  are  not  critical  for  next 
miss  ion . 


If  initialized  to  unity,  all  jobs  that  may  be  deferred  for 
all  missions  are  ignored. 

If  unity,  battle  damage  repair  jobs  may  be  initiated 
concurrently  with  the  first  of  the  other  unscheduled 
maintenance  tasks;  otherwise,  the  battle  damage  tasks  are 
scheduled  to  be  accomplished  first. 

Unscheduled  maintenance  tasks  whose  criticality  is  greater 
than  66  may  be  deferred  ("back-pocketed")  for  a  maximum  of 
LTHDEF  missions. 


Cannibalization  mode  (see  Section  V). 

The  maximum  number  of  "holes"  that  may  be  created  on  a 
single  vehicle  by  cannibalization  (default  =  10000). 

When  DOCANN  is  greater  than  zero,  parts  for  which  the 
CANNTM  is  less  than  -1  may  be  cannibalized  if  the  number 
of  vehicles  that  require  the  part  at  the  unit  is  greater 
than  DOCANN. 

Nominal  task  time  when  a  part  is  cannibalized;  expressed 
as  a  percentage  of  the  nominal  time  for  the  task  segment 
that  specifies  the  part  (default  =  150  percent). 


If  not  zero,  the  SRUs  are  stripped  from  one  of  two  or  more 
LRUs  that  are  waiting  for  repair,  when  vehicles  are  NORS 
because  of  that  LRU.  At  a  GSRF,  an  LRU  will  be  be  similarly 
salvaged,  if  the  total  NMCS  count  in  the  theater  is 
greater  than  or  equal  to  the  value  of  CANSRU. 


If  not  initialized,  the  mission  length  is  extended  such 
that  the  vehicle  will  recover  when  an  available  unit  resumes 
operation;  if  initialized  at  1  and  all  operating  units 
are  out-of-action ,  vehicles  are  captured  during  their  misison. 


ORDIT 


Interrupted  tasks  and  repairs  are  prioritized  when 
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ORDWT 


ORDER 1 


ORDER2 


INDEX 


ORDIT  =  1;  FIFO  if  0.  See  Sections  V,  VII,  and  XI  for 
discussions  of  priority  schemes. 

Waiting  tasks  and  repairs  are  prioritized  when  ORDWT  =  1; 
FIFO  if  0.  See  Sections  V,  VII,  and  XI  for  discussions  of 
priority  schemes. 

Threshold  controlling  theater  response  to  parts  shortages; 
responds  only  if  (Enroute  Parts  +  On-unit  Reparables  - 
Required  Parts)  is  less  than  or  equal  to  0RDER1.  Response 
is  increasingly  restricted  for  ever  lower  values  of  0RDER1 

Threshold  controlling  an  operating  unit's  recourse  to 
lateral  resupply;  seeks  lateral  resupply  only  if  (On-unit 
Reparables  -  Required  Parts)  is  less  than  or  equal  to 
0RDER2 .  (Reparables  are  assessed  only  if  the  shop  is  open 
and  functioning.) 

A  threshold  used  when  checking  repair  jobs  waiting  at  a 
GSRF;  if  exceeded  as  jobs  are  checked,  the  job  is 
processed  without  checking  for  a  higher  priority  job.  The 
appropriate  value  to  set  will  depend  upon  which  of  the  two 
logics  (SHOPRY  =  1  or  2)  is  in  use. 


Card  Type  #3/2 

These  entries  jointly  control  AURA's  mechanisms  for  replacing  lost 
and  heavily  battle-damaged  vehicles  and  for  transferring  and/or 
augmenting  vehicles  with  extended  maintenance  requirements. 


JOBCON  Defines  which  jobs  are  to  be  accomplished  when  a  vehicle 
is  sent  to  a  rear  DS/GS  maintenance  unit: 

If  =  1,  the  maintenance  scheduled  for  the  rear  unit 
includes  all  mandatory  rear-unit  tasks,  all 
other  required  tasks,  and  all  mission  dependent 
deferred  tasks  that  must  be  done  in  rear; 

If  =  2,  above  plus  all  mission  dependent  deferred  tasks; 

If  =  3,  above  plus  all  deferred  tasks; 

If  =  4,  vehicle  is  returned  to  operating  unit  with  all 

non-rear-unit  tasks  remaining. 

FILLAC  Value  controls  use  of  filler  vehicles: 

If  =  1,  only  vehicle  losses  are  replaced  from  the 
filler  force; 

If  =  2,  vehicles  transferred  to  the  rear  for  battle 
damage  repair  are  also  replaced; 

If  =  3,  any  vehicle  transferred  to  the  rear  is  replaced; 

If  =  4,  unit  vehicles  are  augmented  as  for  FILLAC  =  2, 
and  when  a  vehicle's  local  battle  damage 
repair  time  is  expected  to  exceed  MAXMNT  hours; 

If  =  5,  unit  vehicles  are  augmented  for  any  of  previous 
conditions  and  when  a  vehicle's  unscheduled 
maintenance  is  expected  to  exceed  MAXMNT  hours. 

FLF.VEL  The  value  of  FLEVEL  affects  the  decision  to  augment  any 

unit's  vehicles,  and  controls  the  disposition  of  vehicles 
repaired  at  a  rear  unit  and  and  those  transferred  from 
CONUS  to  the  filler  pool.  To  requisition  an  augmentee 
or  to  return  vehicles  from  the  rear: 

If  =  0,  the  number  of  surviving  vehicles  must  be  less 
than  the  number  of  authorized  vehicles; 

If  =  1,  the  number  of  surviving  non-battle-damaged  vehicles 
must  be  less  than  the  number  of  authorized  vehicles 
If  =  2,  the  number  of  surviving  vehicles  must  be  less  than 
the  unit's  shelter  capacity; 

If  =  3,  the  number  of  surviving  non-battle-damaged  vehicles 
must  be  less  than  the  unit's  shelter  capacity. 

When  these  conditions  are  not  met,  newly  repaired  and 
vehicles  newly  arrived  from  CONUS  are  consigned  to  the 
filler  pool . 
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MNTLMT 

MNTF 

MNTR 

QUIK 

R PARTS 

MAXNNT 

EMERG 

NOFUEL 

UNCER 

VBREAK 


Vehicles  whose  projected  ready-to-go  time  exceeds  MNTLMT 
hours  are  transferred  to  a  rear-area  unit  for  maintenance, 
if  the  time  projected  to  ready  the  vehicle  for  a  one-way 
trip  is  less  than  the  time  for  the  remaining  maintenance, 
and  if  the  constraints  imposed  by  MNTF  and  MNTR  (bilow) 
are  also  satisfied. 

Candidates  for  transfer  to  a  rear-area  unit  that  are 
projected  to  require  as  much  as  MNTF  percent  of  the  time 
that  would  be  needed  at  the  rear-area  unit  to  be  readied 
for  the  transfer  will  be  sent  only  if  the  estimated 
maintenance  time  at  the  rear-area  unit  exceeds  MNTR 
percent  of  MNTLMT  hours. 

Fillers  used  to  replace  combat  vehicles  transferred 
to  the  rear  for  maintenance  are  sent  at  the  same  time 
the  combat  vehicle  initiates  the  transfer  if  QUIK  is 
zero;  if  QUIK  is  unity,  the  filler  is  sent  as  soon  as 
the  combat  vehicle  has  completed  its  mission 
and  it  is  decided  that  it  will  be  moved  to  the  rear. 

The  time  for  the  trip  is  entered  on  Card  Type  if 20/77. 

When  the  automatic  parts  generation  feature  is  used, 

RPARTS  percent  of  the  parts  procured  for  the  forward 
operating  units  will  be  placed  at  the  rear-area 
maintenance  unit(s);  these  are  in  addition  to  those  that 
are  transferred  to  the  rear  because  of  tasks  that  must  be 
handled  in  the  rear. 

If  maintenance  of  a  vehicle  in  a  forward  unit  is  projected 
to  extend  beyond  MAXMNT  hours,  the  unit  will  be  augmented 
with  a  filler  vehicle  if  FILLAC  is  4  or  5,  and  a  vehicle  is 
avai lable . 

Number  of  the  emergency  recovery  unit;  when  specified  will 
be  used  for  vehicle  recovery  when  the  support  areas  at 
all  other  units  have  been  closed;  this  unit  may  not  be 
used  for  a  GSRF. 

If  unity,  other  premission  tasks  are  prohibited  when 
refueling  is  being  conducted. 

When  initialized  with  the  number  of  a  distribution  from 
the  TTIME  subroutine,  the  "actual"  unscheduled  maintenance 
task  probabilities  used  in  the  simulation  are  determined 
by  selecting  a  value  from  that  distribution,  assuming  the 
mean  is  the  value  entered  by  Card  Type  ifl . 

A  switch.  If  zero  or  -1,  unscheduled  maintenance  task 
probabilities  are  modified  in  proportion  to  the  Card  Type 
#44  entries.  If  unity,  the  basic  probabilities  are  varied 
by  shop  and  vehicle  type  as  a  function  of  achieved 
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OLDATA 

NEWDTA 


mission  rate.  If  set  to  -1  or  +1,  the  basic  values  are 
used  for  estimating  average  shop  task  times,  average 
resource  requirements  (in  BSECAP) ,  and  initial  parts 
stocks . 

Base  resource  reports  are  generated  when  zero,  and  deferred 
initially  while  equal  to  unity. 

The  time  at  which  theater  resource  reports  are  to  be 
initiated;  only  applicable  if  OLDATA  is  initialized  as 
zero . 
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Card  Type  #3/3 

The  following  control  variables  control  the  automatic  generation  of 
unit  parts  stocks,  when  that  option  is  elected.  (See  Section  VII. 1.) 


OUTFIT  Activates  the  automatic  parts  stock  initialization. 

PMODE  When  unity,  parts  initialization  uses  Kamins' 

approximation;  otherwise  the  Chapter  11  procedures 
from  AFM  67-1  are  used. 


PPRINT 


RANDM 

FULL 

SHORT 

HIATUS 

TOOFEW 

K1L0W 


Controls  output  summaries  of  the  initial  stock  levels  and 
the  parts  pipelines  (see  subroutine  I PARTS ) .  When 
increased  by  10,  residual  parts  levels  are  listed  after 
the  delay  statistics  controlled  by  STATFQ.  When  increased 
by  20,  the  initial  listing  includes  parts  generated  by 
I  PARTS  and  those  entered  manually.  When  increased  by  30, 
model  execution  is  terminated  at  the  end  of  the  parts 
initialization  computations  just  after  the  results  of 
those  computations  have  been  organized  in  the  format 
specified  for  the  basic  Type  #23  Card.  By  storing 
card-image  copies  of  just  that  portion  of  the  output, 
the  user  has  the  needed  #23  Type  Cards  available  for 
subsequent  use.  When  these  cards  are  employed  the  user 
should  check  his  selection  for  the  value  of  the  variable 
CHNRTS .  This  could  be  useful  either  to  avoid  repeating 
that  calculation  for  a  large  number  of  runs,  or  to  permit 
the  user  to  combine  parts  computed  in  two  different  ways 
at  a  single  unit. 

When  unity,  parts  shortages  and  the  location  of  parts  in 
the  pipelines  are  determined  with  samples  from  the  Poisson 
approximation  of  a  binomial  distribution. 

If  unity,  all  parts  are  at  the  unit,  none  enroute,  at  zero 
time  (identified  as  NOPIPE  in  Common). 

Parts  shortfalls  from  "authorized"  levels  (percent)  that 
result  from  system-wide  shortages. 

Delivery  of  parts  in  pipeline  at  the  beginning  of  the 
simulation  are  to  be  delayed  HIATUS  days. 

The  parts  supply  system  is  critically  short  of  a 
percentage  of  the  parts  (equal  to  TOOFEW/ 10)  because  of 
insufficient  numbers  system-wide;  part  numbers  are 
selected  at  random. 

For  parts  that  are  "critically  short"  the  actual  stock 


K2L0W 

ZNMCS 

NEWPRT 

NPART 

CHNRTS 
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level,  as  a  percentage  of  the  nominal  requirement,  is 
selected  at  random  in  the  range  K1L0W  to  (K1L0W  +  K2L0W) . 

When  initialized  to  unity,  parts  that  were  not  available 
to  be  placed  in  the  pipeline  during  parts  initialization 
because  of  shortages  are  obtained  by  removing  them  from 
a  vehicle--i . e . ,  by  creating  a  NMCS  condition.  If  ZNMCS 
is  zero,  a  message  noting  the  shortage  is  printed. 

If  NEWPRT  is  unity,  the  parts  initialization  computations 
are  repeated  for  each  trial. 

The  number  of  the  highest  numbered  LRU  or  SRU 
(default  =  NOPART). 

When  spare  parts  generated  by  the  automatic  parts 
initialization  logic  are  augmented  using  basic 
Type  #23  Cards,  the  NRTS  rates  during  the  simulation 
will  be  the  values  in  the  POLICY  array  if  CHNRTS 
is  zero;  if  CHNRTS  is  unity  the  NRTS  value  on  the 
basic  Type  #23  Card  will  be  used. 

If  a  vehicle  is  damaged  by  enemy  air/artillery  attack 
and  is  not  reparable,  FSALVG  percent  of  the  vehicle's 
spare  parts  not  destroyed  during  the  attack  are  salvaged 
and  added  to  the  serviceables . 


FSALVG 
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Card  Type  #4/1 

SLEEP  Minimum  number  of  off-duty  hours  between  shifts  for 

crewmen . 

REST  Minimum  number  of  minutes  between  missions  for  a  crewman. 

ENDAY  End  of  the  nominal  operating  day  (used  to  control 

accomplishment  of  deferred  maintenance)  (hours). 

EXPED  When  initialized,  the  parts  repair  administrative  delays 

are  reduced  to  1/EXPED  of  the  nominal  time,  if  there  are 
no  serviceables . 

LOADTM  Nominal  time  to  commence  premission  preparation  for  the 
day  (hour-minute). 

LSTTOD  Last  time  for  commencing  morning  premission  activity  (used 
to  limit  expected  time  for  deferred  tasks)  (hour-minute). 

OVERTM  Number  of  minutes  of  overtime  permitted. 

DOWNTM  Parts  may  not  be  cannibalized  from  a  vehicle  with  a 

ready-to-go  time  within  "DOWNTM"  hours. 

CDELAY  The  default  time  for  cannibalization  is  one-half  the 
related  on-vehicle  task  time,  plus  CDELAY  minutes. 

PKGTM  Number  of  minutes  required  to  package  resources  for  an 

intratheater  shipment. 

CEDELY  Initiation  of  all  reconstruction  tasks  is  delayed  by  this 

number  of  minutes  after  an  attack,  to  account  for 
the  preliminary  delays  involved  in  overcoming  the 
disruptive  effects  of  fires,  roadway  damage,  etc. 

SHPDLY  This  delay  is  introduced  to  all  on-  and  off-vehicle- 
related  tasks,  to  account  for  the  disruption 
following  an  attack.  May  also  be  used  to  simulate 
moving  the  support  area. 

PROTME  When  insufficient  vehicles  are  ready  for  a  scheduled 

mission,  and  none  can  be  found  in  the  spare  queue  or  a 
lower  priority  alert,  a  vehicle  can  be  taken  from 
another  scheduled  mission  of  the  same  or  lower  priority  if 
the  mission  time  is  at  least  PROTME  minutes  later  (default 
=  30  minutes) . 

C4TM  Time  for  initial  theater  resource  review  (hours). 

C4INT  Time  interval  in  hours  between  periodic  theater  resource 

reviews,  subsequent  to  the  initial  review. 


Card  Type  #4/2 


STATE 

>  1 

>  2 

>  3 

SELECT 

>  1 
>  2 

MULTI  1 

MULTI  2 

NOSAVE 

NOPOMO 

HR-TH 


If  not  zero,  the  state  of  each  unit's  capability  to 
generate  missions  is  computed  daily  (see  Section  XI. 1). 

Use  of  a  nonzero  entry  is  generally  reserved  for  cases 
that  involve  aircraft. 

Unit-state-data  used  to  select  unit  for  diversion 
Unit-state-data  used  to  decide  when  vehicles  return  to 
owning  unit  (see  MULTI  1) 

Vehicle  unit  assignment  reorganized  nightly  when 
workloads  are  disproportionate  (see  MULTI2) 

When  not  zero,  a  daily  summary  of  the  assigned  missions  is 
prepared  to  facilitate  selection  of  units  for  missions. 

Summary  data  used  when  unit  not  specified 
Summary  data  used  for  reallocating  demands  on  units 
with  attack  delays. 

When  a  unit's  projected  mission-generation  capability  per 
assigned  vehicle  is  greater  by  MULTI  1  percent  than  that 
of  the  unit  owning  a  vehicle,  that  vehicle  is 
retained  and  not  returned  to  the  owning  unit. 

Vehicle  reassignment  (STATE  =  3)  activated  among  units 
whose  projected  missions  per  available  vehicle  differ  by 
more  than  MULTI 2  percent. 

When  NOSAVE  =  1,  records  are  not  saved  for  parts  that  break 
after  an  attack  has  closed  the  shop  that  would  normally 
process  the  repair,  if  the  projected  shop  reconstitution 
time  is  not  earlier  than  the  end  of  the  simulation. 

For  standard  U.S.  organization,  set  to  zero.  When  a 
nonstandard  organization  is  specified,  set  to  the  average 
additional  time  required  for  on-vehicle  tasks,  if  task 
times  are  for  standard  organization. 

The  time  horizon  used  with  the  mission  supply  and  demand 
projections  may  be  changed  from  the  default  values  with 
these  entries;  for  example,  if  the  entries  are  8-12,  24-16 
the  time  horizon  would  be  12  hours  from  0  to  0800  and  16 
hours  from  0801  until  midnight. 
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Card  Type 

SPARE1 

SPARE9 


#4/3 


Provides  nine  unassigned  variables  that  are  available  in 
the  BASIC  labeled  common  statement  for  temporary  use  with 
user  contrived  logic. 
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SPECIFICATION  OF  TASK  CRITICALITY  AND  VEHICLE  STATUS 

The  importance  of  each  vehicle  maintenance  task  for  each  of  the 
missions  that  each  type  of  vehicle  may  be  scheduled  to  undertake  is 
specified  with  a  two-digit  number  between  1  and  99.  The  capability  of 
each  particular  vehicle  to  do  a  particular  type  of  mission  at  any  given 
time  is  also  expressed  with  a  number  generated  in  the  same  way. 

The  interpretation  of  these  numbers  is  specified  in  Table  1.  When 
the  task  criticality  or  the  combat  ready  status  is  specified  by  one  of 
the  numbers  along  the  top,  its  status  for  a  particular  type  of  mission 
is  recorded  in  the  row  corresponding  to  that  mission.  If  the  entry  is 
1,  the  task  is  critical  for  that  mission,  or  the  vehicle  has  a  task  that 
has  been  deferred  that  prevents  that  mission  from  being  accomplished. 

If  task  criticality  is  32,  the  vehicle  may  be  moved  under  its  own  power; 
if  it  is  33,  the  vehicle  is  disabled  until  the  task  has  been 
accomplished,  or  until  it  can  be  towed. 

If  a  task  may  be  deferred  only  until  the  end  of  the  day,  task 
criticality  is  increased  by  33;  if  a  task  may  be  deferred  only  for 
LTHDEF  missions,  task  criticality  is  increased  by  66. 


to 


CRITICALITY  CHART 
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TASK  CRITICALITY  or  VEHICLE  STATUS 

111111111122222222223333 

123456789012345678901234567890123 

010101010101010101010101010101011 

001100110011001100110011001100111 

000011110000111100001111000011111 

000000001111111100000000111111111 

000000000000000011111111111111111 


RESOURCE  REQUIREMENTS  DATA 
Card  Type  #5 


On-vehicle  maintenance  tasks  are  entered  here:  These  can  include 
scheduled  maintenance,  unscheduled  maintenance,  and  battle  damage  tasks. 
As  explained  in  Section  V,  the  organization  and  sequencing  of  all 
vehicle  maintenance  tasks,  other  than  battle  damage  repair  work,  are 
controlled  independently  for  each  vehicle  type  at  each  operating  unit 
using  Card  Type  #29.  Tasks  may  be  handled  either  individually  or  as 
collections  of  unscheduled  tasks  associated  with  the  various  work 
centers  or  shops.  The  first  24  shops  should  be  used  for  such  task 
collections;  Shop  #25  (the  "ready-line"  shop)  and  the  premission  Shops 
#27,  #28,  and  #29  are  handled  somewhat  differently  (see  Section  V  and 
VI)  and  have  a  "flexible  overtime"  policy.  (Periodic  scheduled 
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maintenance  tasks  could  also  be  included  if  AURA  were  modified  to  keep  a 
record  of  total  mission  miles,  rounds,  or  time,  and  to  conduct  those 
tasks  as  required.  At  present  those  tasks  are  handled  by  requiring  them 
to  be  accomplished  with  a  probability  that  is  a  function  of  the  number 
of  days  "on  the  line.") 

Resource  requirements  (maintenance  personnel,  support  equipment, 
and  parts)  and  time  are  entered  following  the  cognizant  shop  number  and 
the  number  of  the  part,  if  any,  that  is  associated  with  the  task.  If 
the  shop  facility  itself  is  required  for  the  task,  or  if  the  task  must 
be  accomplished  at  a  rear  unit,  those  constraints  are  specified  by  the 
entry  in  column  10  (see  note  to  Fig.  3). 

If  the  unit  is  structured  in  a  company  organization,  and  MOSs  of 
the  type  required  are  assigned  at  company  level,  the  numerical 
designation  of  personnel  assigned  to  the  first  company  shall  be 
specified  for  the  task.  Support  equipment  specifications  are  handled  in 
a  comparable  manner.  All  resource  data  are  "packed."  If  only  one  set 
of  MOSs  or  one  piece  of  support  equipment  is  required,  it  should  be 
entered  in  the  left  position.  If  one  of  the  two  sets  of  personnel  is  a 
"load  team"  (see  Card  Type  #15/1)  it  must  be  placed  in  the  left 
position.  As  will  be  noted,  the  number  of  the  first  of  any  alternative 
procedures  should  be  entered  in  columns  40-43. 

Task  networks  are  specified  by  the  entries  in  the  columns  provided 
for  subsequent  and  parallel  task  numbers,  and  for  the  rejoin  flags.  All 
segments  of  a  task  network  are  to  be  associated  with  the  same  shop,  even 
though  maintenance  personnel  and  support  equipment  must  be  borrowed  from 
another  shop  for  some  of  the  task  segments.  Task  networks  will  be 
"chained"  if  the  last  entry  of  a  network  limb  is  the  root  segment  for 
another  network.  Care  must  be  taken  that  no  two  networks  can  both  point 
to  each  other. 

In  a  task  network,  any  segment  that  specifies  a  part  may  be 
followed  immediately  by  a  task  that  can  be  made  to  be  contingent  on 
whether  a  part  is  required;  if  a  part  is  not  required,  the  task  so 
designated  will  be  skipped  and  subsequent  tasks  will  be  considered 
immediately.  This  option  is  activated  by  placing  a  -1  in  the  part 
column  of  a  single  task,  or  of  members  of  a  set  of  parallel  tasks.  (See 
illustration  in  Section  V  of  Volume  I . 1 
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The  task  probability  entered  with  Card  Type  #7  determines  usage  for 
the  root  segment  of  tasks  entered  with  the  shop  collections.  The  task 
probabilities  entered  in  columns  36-39  with  Card  Type  #5  only  apply  to 
the  segments  of  a  task  network  that  follow  the  root  segment  and  to  most 
tasks  that  are  handled  individually  (the  only  exceptions  are  the  tasks 
for  loading  basic  munitions,  which  are  controlled  by  the  probabilities 
that  such  munitions  are  retained  from  the  previous  missions,  which  are 
entered  with  the  mission  data  on  Card  Type  #16). 

When  a  network  splits  into  two  or  more  parallel  paths,  some  of  the 
several  paths  may  be  mutually  exclusive,  others  not  mutually  exclusive; 
the  sign  of  the  task  probability  for  the  task  segments  that  begin  each 
parallel  path  defines  how  that  path  is  to  be  treated.  All  paths  for 
which  the  task  probability  is  negative  are  treated  as  mutually 
exclusive;  tasks  with  positive  probabilities  are  not  mutually  exclusive. 

If  any  parallel  paths  later  rejoin,  the  number  of  the  task  segment 
that  immediately  follows  that  junction  shall  be  entered  in  the  "rejoin 
flag"  column  of  the  initial  task  in  each  parallel  path  that  rejoins.  It 
is  also  mandatory  that  any  parallel  paths  that  split  and  rejoin  must  all 
split  and  rejoin  at  the  same  junctions.  Furthermore,  once  begun,  any 
parallel  paths  that  can  later  rejoin  must  rejoin;  that  is  the  likelihood 
that  activity  continues  along  the  path  until  the  junction  is  reached 
must  be  unity. 

"The  network  mean  time"  normally  is  estimated  internally,  and  need 
only  be  entered  for  task  networks  that  are  not  included  in  the  shop 
collections;  for  such  networks  it  should  be  the  mean  time  through  the 
entire  task  network.  The  "incompatibility  pointer"  defines  the  position 
in  the  LISTIN  array  (Card  Type  #19)  that  contains  the  first  item 
incompatible  with  the  current  simple  task  or  tasks. 

The  criticality  of  each  task  for  any  of  five  missions  is  specified 
with  a  two-digit  integer  whose  binary  equivalent  defines  task 
essentiality  (1)  or  do  for rab i 1 i ty  (0);  if  the  task  may  be  deferred  only 
until  the  end  of  day,  the  criticality  indices  (defined  in  Table  1) 
should  be  increased  by  33;  if  the  task  may  be  deferred  only  for  LTHDEF 
missions,  the  criticality  indices  should  be  increased  by  66.  This  datum 
need  only  be  entered  for  simple  tasks  and  for  the  root  segment  of  a 
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network;  if  no  value  is  entered,  the  default  value  is  32.  Space  has 
also  been  provided  so  that  each  unscheduled  maintenance  task  may  be 
categorized  by  what  will  be  called  the  "task  stress";  this  provision  is 
intended  to  facilitate  future  code  extensions  that  could,  for  example, 
let  task  efficiency  vary  with  task  stress  under  specified  conditions. 

All  tasks  that  are  not  to  be  categorized  as  unscheduled  maintenance 
are  identified  by  entering  a  1  in  column  77.  An  entry  in  column  79 
designates  whether  cross-trained  or  task-assist-qualified  personnel  are 
able  to  handle  this  task.  When  records  are  maintained  on  disk,  an 
alphanumeric  description  of  the  task  may  be  entered  in  columns  81-100. 

Sample  Data:  The  first  task  listed  in  Fig.  3,  Task  #1,  is  assigned 
to  Shop  it 2  and  is  carried  out  by  one  Type  #2  Maintenance  Personnel, 
using  a  piece  of  Type  #2  Equipment.  The  mean  task  time  is  30  minutes 
(i.e.,  10  TTU)  with  the  variance  specified  by  Distribution  Type  ill.  No 
part  is  associated  with  this  task.  If  the  resources  for  this  task  are 
unavailable,  no  alternative  procedure  is  available.  The  task  must  be 
accomplished  before  any  mission  can  be  accomplished  (default 
criticality) . 

The  ill  Task,  carried  out  by  two  Type  it  1  and  three  Type  it 2 

Personnel,  using  both  Type  it 2  and  it 3  Equipment,  is  the  root  segment  of  a 

simple  network;  this  initial  task  requires  1  hour  and  15  minutes  (25 
TTU).  The  task  is  only  critical  when  the  second  or  third  mission  type 
is  to  be  done  (criticality  is  7;  see  Table  4).  If  any  of  the 

incompatible  tasks  (beginning  in  the  61st  field  of  the  INCOMP  array)  are 

in  process,  the  task  may  not  be  started.  Three  mutually  exclusive 
Tasks,  it 3,  it 4,  and  it 5  (denoted  by  the  minus  probabilities),  follow  Task 
itl:  Task  it 3  is  required  40  percent  of  the  time;  #4,  35  percent,  and  it 5, 
25  percent.  An  alternative  procedure  (Task  #1)  can  be  used  for  Task  itl, 
but  for  no  other. 

Task  #6  requires  three  Type  it 3  Personnel  an  average  of  1  hour  (20 
TTU)  using  a  Type  it 3  Equipment;  furthermore,  if  the  vehicle  is  at  a 
forward  location,  it  is  necessary  that  it  be  moved  to  a  rear  maintenance 
unit  to  carry  out  this  task  (specified  by  the  "l"  in  column  10).  Sixty 
percent  of  the  occasions  when  this  task  arises,  a  Type  itl  Part  is 
required;  in  10  percent  of  the  cases  that  a  part  is  removed,  it  must  be 
condemned.  If  any  of  the  tasks  or  shops  listed  in  the  incompatible  task 
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list  (beginning  in  the  67th  field)  are  in  process,  this  task  must  wait. 

Task  #7  is  the  root  segment  for  a  simple  task  network  that  is 
assigned  to  Shop  #3;  Task  iil  takes  two  Type  #3  Personnel  45  minutes  to 
complete.  Part  ii 3  is  required  for  Task  #7  on  50  percent  of  the 
occasions.  If  a  part  is  required,  there  is  a  40  percent  chance  that 
Task  #8  is  required;  if  a  part  was  not  required,  or  if  it  was  and  Task 
#8  also  was  required,  then  there  is  a  30  percent  chance  that  Task  #9 
must  be  performed  to  complete  the  task.  If  two  Type  #3  Personnel  are 
not  available  for  Task  iil  or  Task  #9,  personnel  that  have  been  cross- 
trained  to  replace  these  MOSs  could  be  used;  at  least  one  Type  #3  Person 
is  required  when  Task  #8  must  be  handled,  however,  since  no  personnel 
substitutability  is  indicated  for  this  element  of  the  network. 

Task  #18  is  the  root  segment  for  the  complex  task  network  sketched 
below;  this  network  involves  11  task  segments  and  seven  parts: 


Following  completion  of  the  root  segment  task,  one  of  the  three  mutually 
exclusive  Tasks  #19,  #23,  or  #25  (denoted  by  the  minus  probabilities)  is 
selected,  and  there  is  a  60  percent  chance  that  Task  #24  also  must  be 
done.  If  Task  #24  and  either  #19  or  #23  are  required,  both  paths  must 
be  completed  before  a  check  is  made  to  see  if  Task  #21  is  required. 

Also,  if  Part  #9  had  not  been  required  with  Task  #18,  and  Task  #25  was 
selected  from  the  mutually  exclusive  set,  that  task  is  bypassed  (as 
dictated  by  the  -1  in  the  parts  column  for  Task  #25)  and  a  check  is  made 
to  see  if  Task  #26  is  required. 


Other  tasks  shown  include  the  refueling  Task  #41  (see  Card  Type 
#15),  and  the  scheduled  maintenance  tasks  for  mounting  auxiliary  fuel 
tanks  (#42)  and  for  loading  the  basic  munitions  (#43  and  #44).  The 
coded  part  numbers  for  the  last  three  of  these  tasks  specify  two  Type  #5 
Accessories,  two  #12  and  one  #11  Munition  (3200  *  Class  +  100  x  Number  + 
Type).  The  fuel  tanks  are  required  for  60  percent  of  the  missions;  the 
expenditure  rate  for  the  basic  munitions  is  controlled  by  mission  with 
Card  Type  #16.  Task-ass ist -qua  1 i f ied  personnel  may  be  used  for  the  fuel 
tank  and  Type  #11  Munitions  tasks;  either  cross-trained  or  task-assist- 
qualified  personnel  may  help  with  the  Type  #12  Munition  task. 

The  last  four  tasks  comprise  the  set  of  the  battle-damage  repair 
tasks  as  specified  on  Card  Type  #15/2;  each  has  a  25  percent  chance  of 
needing  attention  when  a  vehicle  is  damaged  and  all  require  that  the 
vehicle  be  towed  (criticality  =  33).  All  parts  are  condemned. 
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Card  Type  #6 
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Alternative  procedures  and  resource  requirements  for  on-vehicle 
maintenance  tasks  are  specified  here.  The  task  numbers  for  alternative 
procedures  specify  the  location  of  the  data  in  the  TSKALT  array  and  are 
distinct  from  the  numbers  that  define  the  nominal  procedures  and 
resources.  As  noted,  additional  alternative  procedures  may  also  be 
specified. 


Sample  Data :  Two  alternative  sets  of  resource  requirements  are  shown; 
the  first  provides  an  alternative  procedure  for  Task  i/3;  two  Type  i/2  and 
one  Type  1  Specialist  can  do  the  job  instead  of  two  Type  i/3  Personnel, 
but  they  require  an  additional  half-hour.  Alternative  procedure  i/2 
indicates  that  the  same  personnel,  working  without  the  Type  i/2 
Equipment,  could  do  Task  i/7  in  an  extra  hour  (35  rather  than  15  TTU) . 


i 
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Card  Type  #7 


These  cards  control  the  incidence  per  mission  of  the  on-vehicle 
maintenance  tasks  associated  with  the  shop  task  collections.  The 
probability  per  mission  (multiplied  by  10,000)  is  entered  for  each  task 
number.  These  data  are  entered  separately  from  the  task  data  entered 
with  Card  Type  65,  so  that  the  same  tasks  may  arise  on  different  types 
of  vehicles  with  different  probabilities. 


Sample  Data :  This  sample  indicates  that  Tasks  61,  #2,  #6,  if 7,  and  it  10 
are  required  after  5.0,  2.53,  8.34,  7.6,  and  3.92  percent,  respectively , 
of  the  missions  done  by  Vehicle  Type  f.‘l. 
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Card  Type  #8 

The  resource  requirements  for  a  parts  repair  job  are  structured 
somewhat  like  those  for  an  ou-vehicle  task.  The  parts  removed  from  a 
vehicle  may  be  of  two  types:  parts  that  may  be  repaired  and  reused,  or 
LRUs  that  have  a  defective  SRU  that  must  be  diagnosed  and  replaced. 

Only  one  SRU  may  fail  at  a  time.  The  repair  of  a  part  may  involve 
either  a  specific  procedure  or  one  of  two  or  more  different  procedures. 
One  procedure  is  assumed  to  apply  when  shop  action  is  required  before  a 
part  is  NRTSed,  rather  than  being  NRTSed  immediately  after  removal  from 
the  vehicle.  If  the  same  shop  procedure  (maintenance  personnel,  support 
equipment,  and  time)  is  used,  whether  the  part  is  repaired  at  the  unit 
or  is  determined  to  require  a  NRTS  action,  only  one  procedure  need  be 
listed.  The  format  used  with  the  Type  #8  Cards  (Fig.  4)  depends  upon 
which  type  of  part  is  being  treated.  The  P 8/1  format  is  used  with 
simple  parts,  the  P8/2  format  is  used  when  more  than  one  procedure  or 
SRU  is  involved,  and  the  *.‘8/3  format  is  used  to  specify  multiple 
procedures,  SRU  replacement  procedures,  and  SRU  repair  procedures.  The 
part  number  or  LRU  number  specified  in  the  TSKRQT  array  (on  Card  Type 
ir 5)  denotes  where  the  REPRQT  array  should  be  entered  for  data  regarding 
its  repair;  therefore,  the  parts  associated  with  various  vehicle  types 
must  each  be  assigned  a  unique  number,  except  for  parts  that  are  common 
to  two  or  more  types  of  vehicles. 

Parts  that  involve  two  or  more  repair  procedures  but  no  SRUs  are 
entered  with  the  PS/2  format  and  are  denoted  by  a  minus  two  in  columns 
24-25  (59-60).  An  LRU  is  denoted  by  a  minus  one  in  the  same  field.  The 
location  of  the  first  repair  procedure,  or  the  first  of  the  SRUs  in  an 
LRU,  is  specified  in  columns  26-30  (61-65).  The  requirements  for  the 
various  procedures  and  the  requirements  for  diagnosing  and  replacing 
each  of  the  SRUs  in  an  LRU  are  entered  using  the  # 8/3  format  and  are 
also  stored  in  the  REPRQT  array.  The  first  repair  procedure  is  always 
used  for  a  part  that  is  checked  in  the  shop  before  being  NRTSed,  rather 
than  being  NRTSed  immediately  after  removal  from  the  vehicle.  If  the 
probability  of  the  first  procedure  is  greater  than  zero,  the  same 
procedure  may  be  selected  when  the  part  is  to  be  repaired  at  the  unit; 
otherwise  the  first  procedure  would  be  used  only  when  the  part  is 
checked  in  the  shop  and  NRTSed. 


REPAIR  REQUIREMENTS  OATA  -  REPAQT  ARRAY  -  OATA  DEPENDENT  FORMAT 
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Fig.  4  —  Vehicle  parts  repair  requirements 
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A  repair  procedure  that  is  numbered  lower  than  NOPART  and  does  not 
require  an  SRU  must  be  distinguished  from  one  that  does  by  a  -1  entry  in 
columns  33-34  (68-69).  If  the  repair  procedures  that  do  not  involve  an 
SRU  are  numbered  between  NOPART  and  NOREP,  the  size  of  arrays  that  use 
NOPART  as  a  dimension  can  be  minimized.  (Furthermore,  the  requirement 
for  a  negative  entry  will  be  avoided,  since  that  entry  is  made 
automatically  except  for  those  LRUs  that  have  procedures  that  do  not 
require  an  SRU,  and  are  numbered  lower  than  NOPART.) 

Each  alternative  procedure,  or  SRU  entry,  also  specifies  (1)  the 
likelihood  that  that  procedure  is  required  or  that  the  SRU  is  faulty, 
and  (2)  the  number  of  the  next  procedure  or  SRU,  if  any.  The 
probabilities  associated  with  the.  alternative  procedures,  or  with  the 
SRUs  in  an  LRU,  must  sum  to  100. 

When  an  SRU  can  itself  be  repaired,  the  location  of  the  first  of 
the  one  or  more  procedures  that  may  be  specified  for  that  repair  is 
listed  in  columns  31-34  (66-69)  of  the  SRU  replacement  data.  If  two  or 
more  procedures  are  given  for  the  repair  of  an  SRU,  the  particular  one 
required  in  a  given  instance  is  selected  on  the  basis  of  the  individual 
procedure  probabilities  entered  in  columns  35-37  (70-72).  As  with  any 
LRU,  the  first  of  the  SRU  procedures  specifies  the  resources  required 
when  the  SRU  must  be.  checked  when  it  is  NRTSed,  rather  than  NRTSed 
immediately  after  removal  from  the  LRU.  If  the  probability  of  the  first 
procedure  is  not  zero  it  may  also  be  selected  when  the  SRU  is  repaired 
at  the  unit. 


Sample  Data :  Repair  procedures  are  illustrated  for  a  simple  part  (#1), 
an  LRU  (#2),  a  simple  part  with  several  possible  repair  procedures  (#9), 
and  for  an  SRU  (#101).  Part  #1  requires  one  Type  #72  Specialist  for  3 
hours  and  18  minutes  to  repair  or  to  check  for  a  NRTS  action,  using  a 
piece  of  Type  #22  Equipment.  An  alternative  procedure  is  listed. 

The  LRU  #2  has  three  SRUs  (#101,  #102,  and  #103)  that  fail  30,  10, 
and  20  percent  of  the  time,  respectively;  in  the  other  40  percent  of  the 
repairs  no  SRU  is  required  and  repair  procedure  #601  is  used.  As  will 
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be  noted,  the  times  and  resources  for  each  of  the  repair  procedures 
differ,  and  in  one  instance,  #102,  an  alternative  procedure  is  listed. 
Also  SRU  #101  may  itself  be  repaired. 

The  #101  SRU  is  repaired  by  one  of  two  procedures--#132  or  #133; 
procedure  #131  is  only  used  when  the  SRU  is  checked  and  NRTSed  (a  blank 
or  zero  in  cols  35-37).  The  maintenance  personnel  and  support  equipment 
are  the  same  for  all  these  procedures,  but  the  work  can  require  as 
little  as  one  hour  (#133)  or  as  much  as  3.3  hours  (#132). 
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Card  Type  #9 


Data  entries  for  alternative  parts  repair  procedures  are  structured 
analogously  to  those  for  alternative  on-vehicle  tasks  and  are  stored  in 
the  REPALT  array. 


Sample  Data'.  This  sample  indicates  that  one  Type  #73  Person  can  repair 
Part  #1  in  5-1/4  hours  without  any  support  equipment;  see  comments  on 
Card  Type  .•••8. 


For  repair  purposes,  support  equipment  is  divided  into  two 
categories;  those  that  are  either  serviceable  or  must  be  repaired,  and 
those  that  also  have  an  intermediate,  partially  mission-capable  state. 
The  former  are  treated  with  the  procedures  that  are  outlined  with  Card 
Type  #10  and  are  stored  in  the  AGEREP  array.  The  latter  category, 
consisting  primarily  of  the  ATE  used  for  testing  and  repairing 
electronics  and  e lectromechanica 1  equipment,  are  described  with  Card 
Types  #22/66  and  #22/77. 

For  the  first  of  these  categories  one  or  more  procedures  may  be 
specified  for  repairing  each  of  these  types  of  support  equipment;  when 
more  than  one  procedure  is  listed,  they  are  assumed  to  be  mutually 
exclusive  and  the  one  that  is  required  for  any  particular  repair  is 
«  selected  by  a  random  process.  The  data  appropriate  for  each  type  of 

support  equipment  are  found  in  that  column  of  the  AGEREP  array  that 
corresponds  to  the  number  that  designates  that  type  of  equipment. 

The  shop  to  which  each  support  equipment  repair  is  assigned  and  the 
likelihood  that  the  equipment  is  broken  following  each  use  are  entered 
in  columns  11-15  and  16-20;  when  a  single  procedure  is  always 
appropriate,  the  time,  maintenance  personnel,  and  other  support 
equipment  needed  to  repair  the  unserviceable  one  are  entered  next.  If 
the  repair  requirements  vary  depending  upon  circumstances,  a  "-1”  is 
entered  in  columns  29-30  of  the  basic  entry,  and  the  entry  in  column 
31-35  specifies  the  location  in  the  AGEREP  array  of  the  first  of  the 
multiple  repair  procedures.  For  those  procedures  columns  16-20  contain 


the  probability  that  each  of  the  multiple  procedures  will  be  required, 
and  columns  11-15  spe.cify  the  location  of  the  next  procedure. 

In  all  cases  an  alternative  set  of  resources  may  be  specified  for 
accomplishing  the  nominal  repair. 


Sample  Data :  Repair  requirements  are  shown  for  two  types  of  support 
equipment,  112  and  #3.  Their  repair  is  assigned  to  Shops  ill  and  it 3.  The 
likelihood  that  a  piece  of  Type  "2  Equipment  is  found  faulty  following 
each  use  is  6.26  percent;  for  the  Type  113  Equipment,  it  is  0.78  percent. 
Two  Type  ?; 3  Personnel  always  repair  the  11 3  Equipment,  and  the  nominal 
task  time  is  2.5  hours.  One  of  three  different  procedures  may  be 
required  to  repair  a  Type  ill  Equipment;  25  percent  of  the  time  one  Type 
11 2  Personnel  can  repair  it  in  two  hours;  70  percent  of  the  same 
specialist  takes  four  hours,  and  five  percent  of  the  time  five  days 
(2400  TTU)  must  elapse  before  the  repair  is  accomplished  (this  type  of 
procedure,  one  that  consumes  time  but  no  maintenance  personnel  or 
support  equipment,  ca  -.  be  used  to  approximate  the  effect  of  waiting  for 
a  critical  piece-part  from  another  location). 

The  last  entry  illustrates  how  the  ATE  equivalent  of  an  equipment 
type  is  identified.  In  this  instance,  a  i! 3  Type  ATE  station  is 
identified  as  a  piece  of  Type  ••••18  Equipment;  the  minus  sign  denotes  the 
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Resource  requirements  for  assembling  munitions  are  specified  and 
stored  in  the  MUNRQT  array;  the  number  of  the  munitions  type  determines 
the  column  in  that  array  in  which  the  data  are  filed.  The  quantity  of 
munitions  to  be  assembled  for  each  task  should  be  selected  such  that  the 
buildup  time  is  no  greater  than  two  to  three  hours,  so  that  the 
simulated  assembly  activities  will  be  responsive  to  sudden  shifts  in 
munitions  requirements.  The  default  value  for  the  number  of  munitions 
assembled  is  12.  The  requirements  for  alternative  procedures,  when 
specified,  are  also  filed  with  these  cards  in  the  MUNRQT  array;  these 
data  should  not  be  filed  in  columns  defined  by  any  of  the  munition  types 
cons idered . 


Sample  Data :  Assembly  requirements  are  shown  for  six  types  of 
munitions.  The  assembly  of  six  Type  111  Munitions  takes  three  Type  1165 
Personnel  two  hours  (40  TTU)  using  a  unit  of  Type  #21  Equipment.  If 
available,  cross-trained  personnel  may  replace  the  Type  #65  Personnel  in 
assembling  the  Type  #1  Munitions.  For  assembling  #4  and  #6  Munitions, 
task-assist-qualified  personnel  may  assist,  but  not  replace,  the  normal 
personnel.  In  one  instance  (the  #5  Munitions)  an  alternative  procedure 
permits  assembly  without  special  equipment,  but  requires  an  additional 
1-3/4  hours  (35  TTU). 
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Card  Type  #12 
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These  cards  permit  the  user  to  specify  up  to  five  standard  combat 
loads  (SCI.)  for  each  combination  of  vehicle  type  and  mission.  The 
preferred  loading  is  listed  first;  the  least  acceptable  load  is  listed 
last.  An  effectiveness  proxy  may  be  entered  for  each  SCL;  these  values 
are  summed  during  the  simulation  for  each  mission  that  is  initiated  and 
does  not  abort,  and  provide  an  overall  measure  of  effectiveness.  The 
user  must  be  careful  to  ensure  consistency  between  the  effectiveness 
proxies  for  the  different  types  of  vehicles  and  missions. 

When  the  program  is  executed,  resources  are  sought  first  for  the 
preferred  munitions,  and  then  for  the  secondary  (less  effective) 
options.  Resource  requirements  for  the  various  SCLs  are  listed  in  the 
SCLRQT  array. 


Sample  Data :  Combat  loading  preferences  are  shown  for  two  missions  for 
Vehicle  Type  it  1 ;  primary  and  secondary  choices  have  been  defined  in  both 
cases.  The  first  card  image  indicates  that  when  a  Vehicle  Type  #1  is 
sent  on  a  Type  #1  Mission,  loaded  with  SCL  #1,  110  effectiveness  units 
are  tallied;  if  the  required  munitions  or  accessories  are  not  available, 
mission  effectiveness  would  drop  to  90  when  SCL  #2  is  used. 
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Card  Type  #13 
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The  munitions  loading  requirements  for  the  various  SCLs  are  entered 
here.  Since  the  SCL  number  denotes  the  column  in  the  SCLRQT  array  in 
which  the  data  are  stored,  distinct  SCLs  are  required  for  each  vehicle 
type,  unless  the  time  requirements  are  the  same.  Configuration  type 
represents  a  specific  combination  of  SCL  and  vehicle  accessories. 
Resources  needed  to  set  up  the  vehicle  configuration  specified  in 
columns  6-9  are  handled  with  the  next  card  type.  Either  one  or  two  sets 
of  munitions  may  be  specified.  If  the  personnel  (crewmen  or  other 
munitions  MOSs)  and  support  equipment  requirements  for  the  two  tasks  are 
the  same,  the  tasks  may  be  done  in  series  if  there  are  insufficient 
resources  available  for  both.  Otherwise,  both  must  wait  until  all 
resources  are  available,  unless  a  subordinate  SCL  may  be  loaded. 


Sample  Data :  These  data  specify  that  SCL  #1  involves  Configuration  #1 
and  that  12  Type  #1  and  two  Type  #5  munitions  are  to  be  loaded.  Four 
Type  #62  Personnel  require  a  #31  Equipment  for  45  minutes  to  load  the  #1 
Munitions,  and  three  Type  #63  Personnel  take  30  minutes  with  a  #32 
Equipment  to  load  the  #5  Munitions.  Cross-trained  or  task-assist- 
qualified  personnel  may  be  used  for  the  first  task  (the  3  in  column  15), 
but  no  substitutions  are  permitted  for  the  second. 
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Card  Type  #14 


The  resource  requirements  and  task  times  for  all  vehicle 
configurations  are  entered  using  Card  Type  #14.  Either  one  or  two  tasks 
may  be  specified.  The  configuration  number  denotes  the  position  of  the 
data  in  the  CONFIG  array.  Accessories  are  considered  to  be  returned 
when  the  vehicle  returns  from  a  mission  and  are  returned  to  stock  if 
inappropriate  for  the  next  mission.  When  the  accessories  that  are  to  be 
represented  are  consumed- - i .e . ,  dropped  or  damaged  in  combat--they 
cannot  be  handled  here,  but  must  be  treated  as  a  special  task  assigned 
to  Shop  # 25  (see  the  Card  Type  "5  discussion  for  these  special  tasks). 

When  a  vehicle  must  be  reconfigured  to  meet  the  requirements  of  a 
different  mission  (or  because  the  required  ammunition  stocks  are 
depleted),  the  time  required  to  remove  the  accessory  is  assumed  to  be 
equal  to  the  time  specified  here  for  equipping  the  vehicle.  If  either 
of  the  sets  of  accessories  is  common  to  the  two  configurations,  only  the 
dissimilar  accessories  are  ''changed"  during  a  reconfiguration.  Also,  as 
with  such  descriptors  in  the  other  kinds  of  tasks,  the  maintenance 
personnel,  support  equipment,  and  time  requirements  may  be  satisfied 
with  a  null  entry;  if,  for  example,  the  same  crew  using  the  same 
equipment  loads  two  sets  of  accessories  in  sequence,  the  descriptors  for 
the  second  reconfiguration  task  could  be  limited  to  the  accessory,  with 
null  entries  for  personnel,  support  equipment,  and  time;  the  total  time 
would  be  listed  for  the  first  task. 


Sample  Data:  Two  tasks  are  required  for  Configuration  #1.  In  the  first 
case  two  Type  #62  Personnel  are  to  mount  one  Type  #2  Accessory  and  will 
require  30  minutes  using  a  piece  of  #34  Equipment.  The  second  task 


mounts  one  Type  #4  Accessory  in  24  minutes;  again  two  #62  Personnel 
required.  Cross-trained  personnel  may  be  used  for  either  task,  as 
designated  by  the  1  in  columns  10  and  30. 


Card  Type  #15 


Miscellaneous  vehicle  data  are  entered  using  Card  Types  #15/1, 
#15/2,  and  #16.  The  first  entries  on  #15/1  permit  the  user  to  specify 
two  delays  in  which  no  specific  tasks  are  accomplished;  one  immediately 
after  the  vehicle  arrives  in  a  bivouac  area  and  one  before  the  pre¬ 
mission  maintenance  tasks  are  begun.  The  values  specified  might  be 
chosen  to  reflect  parking,  debriefing  time,  inspections,  or  various 
scheduling  inefficiencies.  The  quantity  of  fuel  (in  tens  of  gallons) 
and  the  appropriate  task  number  are  specified  next.  The  approximate 
expected  values  that  are  entered  for  unscheduled  maintenance  time  and 
for  total  mission  t  ime  are  only  used  for  projecting  the  future  supply  of 
ready  vehicles,  and  only  for  vehicles  that  have  not  yet  returned;  the 
user  should  derive  these  values  from  the  various  data  entered  with  Card 
Types  #5,  .';7,  and  . 

If  the  specifications  for  a  munitions  load  team  are  entered,  only 
one  load  team  will  be  permitted  to  work  on  any  given  vehicle  at  a  time; 
that  constraint  will  be  observed  even  when  substitute  or  alternative 
personnel  are  employed  to  make  up  the  required  load  team.  In  AURA,  the 
load  team  is  usually  the  vehicle's  crew.  For  support  equipment  types 
entered  into  the  special  equipment  fields,  it  is  assumed  that  only  one 
piece  of  such  equipment  need  be  present  at  a  vehicle  to  satisfy  all 
concurrent  task  demands.  When  a  vehicle  is  always  to  be  loaded  with 
some  minimal  kinds  of  munitions,  those  types  should  be  entered  in  the 
last  fields  on  Card  Type  #15/1  and  not  included  in  the  mission-dependent 
munitions  requirements.  These  munitions  are  referred  to  as  basic 
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munitions.  These  entries  and  the  retention  data  on  Card  Type  #16  are 
used  in  assessing  the  demands  for  munitions  assembly;  the  resource 
requirements  for  loading  these  basic  munitions  must  be  entered  with  Type 
#5  Cards  (e.g.,  see  Tasks  #43  and  #44). 

The  first  entry  on  Card  Type  #15/2  is  an  administrative  delay  that 
will  be  imposed  when  a  vehicle  is  newly  arrived  at  the  unit.  When 
vehicle  battle-damage  repair  tasks  are  specified,  the  root  segments  of 
those  tasks  should  be  arranged  in  a  numerically  ordered  set;  the  first 
and  last  task  numbers  of  that  set  are  entered  next  on  this  card.  The 
next  entry  is  the  probability  that  each  part  will  be  recoverable  from 
vehicles  that  are  too  badly  damaged  for  repair  and  must  be  salvaged.  A 
separate  set  of  tasks  may  be  specified  for  the  vehicle  damage  inflicted 
by  enemy  air/artillery  attacks  on  the  bivouac  area;  the  root  segments  of 
these  tasks  should  also  form  a  numerically  ordered  set.  If  a  number  of 
missions  is  entered  in  the  battle  damage  spares  column,  quantities  of 
the  spare  parts  that  would  be  required  for  battle  damage  repairs  are 
automatically  stocked  at  each  unit.  The  numbers  of  parts  stocked  are 
the  numbers  that  would  be  expected  to  be  required  if  a  number  of 
vehicles  were  each  operated  the  specified  number  of  missions;  the  number 
of  vehicles  is  either  the  number  of  each  type  initially  at  each  unit  or, 
if  OUTFIT  is  not  zero,  the  number  specified  on  the  #23/70  Type  Cards. 

The  next  two  entries  on  Card  Type  #15/2  are  used  to  specify  any 
personnel  or  equipment  that  must  be  maintained  with  each  vehicle  that  is 
to  be  placed  around  the  bivouac  area  on  overwatch  duty.  The  next  entry 
specifies  the  unit  number  of  that  rear  unit  where  vehicles  of  the 
specified  type  are  taken  for  DS/GS  maintenance.  Initializing  the  next 
entry  declares  that  this  vehicle  may  be  designated  for  assignment  to 
"special  duty"  and  will  be  given  priority  when  vehicle  shelters 
allocated  to  this  role  are  assigned  (see  Card  Type  #19/1).  When  a  "l" 
is  entered  in  this  field,  a  vehicle  requirement  for  the  highest  numbered 
mission  that  this  vehicle  type  may  be  assigned  to  (col.  35  on  Card  Type 
#15/1)  is  interpreted  as  "special"  duty. 

The  last  three  entries  on  the  #15/2  Type  Card  provide  the  user  with 
options  for  starting  a  mission  despite  the  unavailability  of  certain 
basic  munitions.  If  any  of  these  three  fields  is  not  zero  (or  null), 
the  vehicle  will  be  permitted  on  a  combat  mission  without  the 
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corresponding  munitions  on  Card  Type  #15/1,  and  the  entry  is  interpreted 
as  the  percentage  degradation  to  be  applied  to  the  overall  mission 
effectiveness  recorded  in  the  effectiveness  proxy  when  the  vehicle  is 
sent . 


Sample  Data-.  For  Vehicle  Type  #1,  there  is  a  six-minute  postmission 
delay.  Fueling  requires  five  units  (50  gallons)  of  POL;  the  time  and 
personnel  required  are  specified  with  Task  #41.  The  vehicle  can  be 
assigned  to  three  different  missions.  Approximate  time  for  unscheduled 
maintenance  and  for  a  complete  mission  are  60  and  150  minutes.  A 
munitions  load  crew  consists  of  four  Type  #62  Specialists;  one  piece  of 
Type  #2  or  Type  #4  Support  Equipment  will  satisfy  all  concurrent  demands 
for  either  of  those  types  of  equipment.  The  basic  munitions  that  are  to 
be  loaded  for  all  missions  consist  of  one  Type  #11  Munitions  and  two 
Type  #12  Munitions. 

When  a  Type  #1  Vehicle  returns  to  a  different  unit  or  is 
transferred  to  a  different  unit,  an  hour  is  required  for  various 
administrative  procedures.  For  vehicles  that  receive  battle  damage  in 
combat,  tasks  are  selected  from  Tasks  #101  through  #104,  inclusive.  For 
vehicles  too  damaged  to  be  repaired,  40  percent  of  the  parts  are 
salvaged;  those  recovered  are  selected  at  random  from  the  vehicle  parts 
list. 

No  repair  tasks  are  specified  for  vehicles  damaged  by  enemy 
air/artillery  rear  area  attack.  Spare  parts  are  stocked  at  each  unit 
for  repairing  battle  damage  sustained  in  mission  operations,  on  the 
assumption  each  vehicle  will  run  an  average  of  14  combat  missions. 

If  a  vehicle  is  to  be  placed  on  alert,  two  Type  #2  Personnel  and  a 
Type  #1  Equipment  must  be  assigned.  When  it  is  necessary  for  Type  # 1 
Vehicles  to  have  maintenance  done  in  the  rear,  the  vehicles  are  to  be 
moved  to  Unit  #5. 


Card  Type  #16 


The  only  mission  data  used  in  AURA  are  entered  here.  For  each 
vehicle  type,  and  each  of  the  missions  that  that  vehicle  can  run, 
estimates  are  entered  for  the  duration  of  the  mission,  the  expected 
attrition  and  battle  damage,  abort  rate,  and  munitions  expenditures; 
different  attrition  levels  may  be  specified  for  each  of  five  blocks  of 
time.  If  vehicles  of  this  type  and  mission  are  permitted  to  "jump  off" 
late,  that  allowance  is  also  entered.  If  the  members  of  a  mission  are 
to  return  together,  rather  than  independently,  a  "l"  is  entered  in  the 
final  field. 


Sample  Data :  This  card  image  indicates  that  the  nominal  mission  time 
for  Mission  Type  #1  with  Vehicle  Type  #1  is  1-1/2  hours,  and  that 
departure  up  to  10  minutes  after  the  scheduled  mission  time  is 
acceptable.  One  percent  of  the  vehicles  abort,  10  percent,  on  the 
average,  return  with  their  mission  dependent  munitions,  and  20  percent 
retain  their  basic  munitions.  For  the  first  day,  6  percent  of  the 
vehicles  are  lost  for  each  combat  mission;  4.5  percent  are  lost  on  the 
second  through  third  days,  3.2  percent  on  the  fourth  through  seventh 
day,  2  percent  from  the  eighth  to  the  15th  day,  and  0.8  percent 
thereafter.  Five  times  as  many  vehicles  are  damaged  as  are  lost,  and  8 
percent  of  the  damaged  vehicles  can  be  salvaged.  As  noted  on  Card  Type 
#15/2,  40  percent  of  the  parts,  selected  at  random,  are  recovered.  When 
a  vehicle  is  lost  in  combat  the  crewmen  survive  only  15  percent  of  the 
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Card  Type  #17/1 


'v"lf  unit  is  fixed,  enter  1;  if  mobile,  enter  2 


Miscellaneous  unit  data  are  entered  with  Card  Types  #17/1  and 
#17/2.  The  kind  of  unit  is  entered  in  the  first  field  following  the 
unit  number;  1  denotes  a  unit  at  a  fixed  location,  and  2  a  mobile  unit. 

A  null  should  generally  be  entered  in  the  next  field.  A  "l"  entered 
here  extends  the  mean  on-vehicle  task  times  by  NOPOMO  time  units. 

If  the  maintenance  personnel  at  the  unit  have  been  cross-trained 
for  certain  tasks,  or  have  been  qualified  to  assist  on  various  tasks,  a 
"l"  should  be  entered  as  appropriate  in  the  next  two  fields.  The  entry 
in  columns  31-35  is  used  to  control  the  assignment  of  munition  assembly 
personnel  in  Shop  #30  after  all  immediate  demands  have  been  satisfied; 
additional  assembly  tasks  are  defined  and  initiated  until  the  total 
number  of  ongoing  tasks  is  equal  to  the  value  entered. 

The  number  of  vehicle  shelters  (if  any)  is  specified  in  columns 
31-35.  The  average  number  of  vehicles  that  may  be  accommodated  in  each 
shelter  (times  10)  is  entered  in  columns  36-40.  The  number  of  these 
shelters  that  is  to  be  allocated  preferentially  to  "special"  duty 
vehicles  is  entered  in  columns  41-45;  damage  to  these  shelters  and  their 
contents  will  be  distinguished  from  that  for  the  other  shelters. 

The  last  entry  is  the  unit's  POL  storage  capacity;  that  capacity 
should  be  expressed  in  the  same  units  used  for  specifying  POL  supplies 
on  Card  Type  #27  and  the  vehicle's  per-mission  consumption--normally 
tens  of  gallons.  Since  this  value  cannot  exceed  32750  it  may  be 
necessary  to  select  a  different  unit  of  measure--barrels ,  for  example. 

The  last  two  entries  permit  the  user  to  control  a  special 
relationship  between  the  "probability  that  a  vehicle  is  unable  to  reach 
the  battle  area"  and  the  "percentage  damage"  to  one  part  of  the  unit's 
bivouac  area  (i.e.,  Facility  #35).  The  "damage  limit"  identifies  that 
percentage  damage  beyond  which  access  is  impossible,  and  the  exponent 
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controls  the  manner  in  which  the  probability  varies  between  no  damage 
and  the  "limit,"  as  discussed  in  Section  IX. 


Sample  Data :  The  sample  data  indicate  that  Unit  11 1  is  fixed  and  has 
cross-trained  personnel.  At  least  four  munitions  assembly  tasks  are  to 
be  ongoing  at  all  times.  The  unit  has  4ft  shelters,  and  an  average  of 
1.2  vehicles  may  be  housed  in  each  shelter. 


-  58  - 


Card  Type  #17/2 


The  actual  times  for  various  tasks  that  are  drawn  from  the 
specified  distributions  may  be  modified  to  reflect  various  schemes  of 
work  speedup.  The  HURRY,  REDUCE,  and  SAVE  arrays  control  these  arrays 
according  to  the  relationship: 


Task  Time  =  HURRY! i)  *  [Mean  Time  -  REDUC(i)]  -  SAVE(i) 


where  represents  the  value  selected  from  the  distribution  j,  and 

i  =  1  for  on-vehicle  tasks 
=  2  for  premission  tasks 

=  3  for  parts  and  supply  equipment  repair  jobs 
=  4  for  munitions  assembly  jobs 
=  5  for  combat  engineering  tasks 


HURRY 

REDUCE 

SAVE 


Percentage  of  nominal  task  time 
Mean  time  reduction  in  minutes 
Overall  task  time  reduction  in  minutes 


These  procedures  may  be  used  to  modify  the  many  input  values  on 
Card  Types  #5,  #6,  #8,  #9 ,  #10,  #11,  #13,  #14,  and  #38,  by  entering 
values  for  HURRY,  REDUCE,  and  SAVE  with  Card  Type  #17/2.  Different 
values  may  be  specified  for  each  of  the  five  groups  of  tasks  at  each 
unit.  If  no  unit  number  is  entered,  the  values  will  be  the  same  at  all 
units.  When  these  values  differ  from  the  default  values  of  100,  0,  and 
0,  task  times  are  computed  as  shown  above. 


-  59  - 


Sample  Data :  Card  Type  #17/2  indicates  that  premission  tasks  are  to  be 
accomplished  in  80  percent  of  the  nominal  times  at  Unit  #1,  and 
equipment  repairs  are  to  consume  30  percent  more  than  the  normal  time  at 
Unit  # 2. 
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Card  Type  #18 
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These  cards  are  used  to  specify  the  beginning  of  the  "day"  shift 
for  each  of  the  30  shops  and  the  fraction  of  the  tasks  for  each  of  the 
shops  that  require  a  sheltered  vehicle  to  be  exposed  to  a  higher 
likelihood  of  damage.  The  permissible  entries  for  shift  changes  are 
limited  to  even-valued  hours  between  zero  (midnight)  and  10  (1000 
hours);  the  two  12-hour  shifts  are  presumed  to  be  the  same  for  the  same- 
numbered  shops  at  all  units.  When  an  operating  unit  is  attacked,  each 
sheltered  vehicle  is  checked  as  to  which  shops  are  engaged  in  tasks  on 
the  vehicle;  exposure  to  the  higher  damage  level  is  determined  on  a 
random  basis. 

Tasks  associated  with  Shop  # 25,  or  the  ready-line  shop,  and  with 
the  premission  shops  (Shops  (*27,  #28,  and  #29),  are  treated  differently 
at  the  time  of  their  shift  change.  These  shops  have  a  flexible  overtime 
policy  such  that  no  ongoing  tasks  are  interrupted  as  a  result  of  the 
shift  change,  but  are  completed  before  the  personnel,  usually  crewmen, 
are  released. 


Sample  Data :  The  day  shift  commences  at  0400  for  Shops  #27  and  #28  and 
at  0600  for  Shops  #25  and  #29;  all  others  change  shift  at  0800. 

Vehicles  must  be  left  partially  exposed  in  their  shelters  a  percentage 
of  the  time  that  Shops  #1,  #4,  ;;7,  and  #29  work  on  the  vehicles;  this 
occurs  30  percent  of  the  time  for  Shop  #1,  20  percent  for  Shops  #4  and 
#7 ,  and  60  percent  for  Shop  #29 . 
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Card  Type  #19 


All  incompatible  on-vehicle  task  data  are  stored  in  the 
one-dimensional  LISTIN  array.  For  each  task  that  may  not  be  initiated 
while  other  tasks  are  under  way  or  until  specific  tasks  have  been 
completed,  the  entry  on  Card  Type  #5  (i.e.,  TSKRQT  (-,11))  specifies  the 
first  position  in  the  LISTIN  array  for  the  relevant  incompatibility 
data.  Whenever  an  attempt  is  made  to  initiate  a  task,  all  tasks  being 
conducted  on  that  vehicle  are  checked  to  see  if  they  are  incompatible. 

To  ease  the  specification  of  incompatibilities,  entire  groups  of  shops 
and  tasks  and  task  segments  may  be  specified  as  well  as  individual 
tasks . 

The  task  numbers  of  the  individual  tasks  that  are  incompatible  are 
entered  first  and  the  TASKQ  is  searched  to  see  if  any  of  those  tasks  are 
in  progress.  If  the  task  can  not  be  processed  when  other  shops  are 
working  on  the  vehicle,  the  number  "-l"  is  entered,  followed  by  the 
first  and  last  shop  number;  one  or  more  shop  number  pairs  may  be  listed 
in  sequence.  If  the  task  is  incompatible  with  an  entire  block  of  task 
numbers,  the  number  "-2"  should  be  entered  and  followed  by  the  first  and 
last  task  number  in  that  block  (several  task  number  pairs  may  be  entered 
for  several  incompatible  blocks  of  tasks).  If  the  task  must  not  be 
started  until  after  a  set  or  sets  of  task  segments  are  completed,  the 
number  "-3"  should  be  entered  and  followed  by  the  first  and  last  task 
segment  numbers  of  each  such  set  (several  task  segment  pairs  may  be 
entered) .  A  zero  entry  in  the  LISTIN  array  denotes  the  end  of  that 
particular  sublist  of  incompatibilities. 


Sample  Data-.  These  data  are  filed  in  the  61st  thru  75th  elements  of  the 
linear  LISTIN  array.  Data  in  columns  6-30  specify  those  activities  that 
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may  not  be  ongoing  when  Task  # 2  is  to  be  initiated;  the  first  two 
numbers  refer  to  Tasks  #6  and  #7.  The  number  "-l"  signals  that  the 
following  two  numbers  are  the  first  and  last  of  the  ranges  of  shops  that 
may  not  be  active;  thus  Task  #2  may  not  be  started  if  Shop  #5,  # 6,  #7, 

# 8,  or  #9  is  performing  a  task  on  the  vehicle. 

Data  in  columns  36-75  similarly  specify  that  Task  #6  may  be 
initiated  if  Task  #66  or  any  job  by  Shop  #7  is  in  progress;  furthermore 
it  may  not  be  started  if  any  task  .number  in  the  range  #76  to  #96, 
inclusive,  is  in  process. 

The  first  entry  of  an  incompatibility  list  is  specified  on  a  Card 
Type  #5  by  naming  the  appropriate  element  in  the  linear  LISTIN  array;  in 
this  case,  Task  #6  specified  element  #67,  since  Task  #66  is  the  67th 
element.  If  some  other  task  was  incompatible  only  with  Tasks  #76 
through  #96,  the  incompatibility  pointer  should  specify  #71,  reusing  a 
part  of  the  Task  #6  list,  thereby  saving  storage  space. 
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INITIAL  STOCKS  OF  UNIT  RESOURCES 


The  next  eight  types  of  cards  (#20  thru  #27)  define  resource 
availability  at  zero  time  for  each  of  the  combat  units.  These  data  are 
required  for  each  type  of  each  of  the  eight  resource  classes  that  the 
user  has  distinguished  in  his  descriptors  of  task  requirements.  These 
data  may  be  entered  separately  for  each  unit;  or,  if  no  unit  is 
specified  (except  for  vehicles,  crewmen,  and  POL),  the  same  quantity  of 
each  class  and  type  of  resource  is  provided  at  each  unit.  (When  all  but 
one  unit  or  only  a  few  units  have  the  same  quantity  of  a  resource,  the 
resource  can  first  be  entered  for  all  units  with  a  zero  unit  number,  and 
then  corrected  for  that  unit(s)  with  a  different  quantity.) 

Other  aids  are  available  for  Card  Types  #21,  #22,  and  #23.  When  an 
"88"  is  encountered  in  the  "j"  field  for  any  of  these  card  types,  two 
more  entries  are  expected:  #U1  and  #U2.  These  entries  designate  that 
the  entire  stockage  array  for  that  class  of  resource  is  to  be  copied 
from  Unit  #U1  into  the  storage  space  for  Unit  #U2 .  If  this  card  is 
placed  at  an  intermediate  point  in  the  entries  for  Unit  #U1,  only  the 
data  entered  to  that  point  are  copied  for  Unit  #U2.  A  more 
sophisticated  aid  is  available  for  parts  data;  it  automatically 
generates  parts  stocks  and  initializes  the  parts  pipelines. 

The  quantities  of  all  types  of  these  various  resources  that  are 
available  in  depots  to  replace  losses  may  also  be  specified  with  the  #20 
through  #27  Type  Cards.  When  a  "99"  is  entered  in  the  "J"  field  for  any 
of  these  card  types,  the  total  numbers  of  resources  of  types  I  through  I 
+  9  that  are  available  at  time  zero  are  listed  in  the  ten  5-column 
fields  in  columns  11-60,  where  I  is  the  resource  type  listed  in  columns 
6-10  (see  Card  Type  #23/99). 
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Card  Type  #20 
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Initial  vehicle  inventories  may  include  up  to  five  different  types 
of  vehicles  at  each  operating  unit.  This  card  type  is  used  to  specify 
the  initial  inventory  of  each  type  of  vehicle  and  the  initial  number  of 
crews  qualified  for  that  type  of  vehicle  at  each  unit.  The  total  number 
of  vehicles  in  the  simulation  at  any  time  is  limited  to  the  size  of  the 
ACN  array  (i.e.,  MAXACN),  and  the  total  number  of  crews  is  limited  to 
the  size  of  the  PILOT  array  (i.e.,  NOCREW). 

The  Type  #41  and  Type  #42  Cards  are  used  in  conjunction  with  Card 
Type  #20  for  initializing  vehicle  configurations  for  various  missions 
and  for  initializing  the  status  of  vehicle  maintenance;  those  cards  must 
be  entered  after  the  Type  #20  Cards. 

The  vehicles  of  a  given  type  at  any  particular  unit  may  be 
separated  into  two  or  three  companies  by  entering  a  "2"  or  "3"  in  the 
"Co"  column.  When  this  is  done,  maintenance  personnel  and  support 
equipment  may  be  assigned  separately  to  each  company,  rather  than  all 
vehicles  drawing  upon  a  common  group  of  such  resources.  Organization  of 
those  resources  is  controlled  by  the  ALTPEO  and  ALTAGE  arrays  that  are 
entered  with  Card  Types  #45/1  and  #46. 

The  Type  #20/77  Cards  are  used  to  initialize  the  pool  of  "filler" 
vehicles,  if  any,  and  to  specify  the  time  required  (usually  hours)  to 
move  the  vehicle  to  the  operating  unit  when  it  has  been  assigned.  The 
Type  #20/99  Cards  impose  constraints  on  the  number  of  vehicles  of  each 
type  that  are  available  to  replace  losses  incurred  during  combat 
operations  or  from  rear  area  attacks.  The  availability  and  delivery 
delays  for  these  replacement  vehicles  are  controlled  by  the  Type  #43 
Cards;  these  vehicles  are  in  addition  to  those  that  may  be  designated 
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for  the  filler  force.  Each  filler  vehicle  and  each  replacement  vehicle 
is  moved  by  a  crew  that  is  presumed  to  be  reassigned  to  the  operating 
unit  on  arrival . 


Sample  Data:  Units  #1  and  #2  each  have  48  Type  #1  Vehicle  organized 
into  two  companies;  Unit  it  1  has  54  crews  and  Unit  #2  has  60.  Units  #3 
and  #4  also  have  Type  #1  Vehicles;  the  assignment  is  24  vehicles  at  Unit 
#3  and  18  at  Unit  #4.  Twenty- four  it  1  Type  Vehicles  are  available  in  the 
theater  as  fillers  and  can  reach  their  assigned  unit  in  two  hours.  In 
addition,  72  f;l  Type  Vehicles  are  available  for  replacing  vehicles  lost 
in  combat,  and  can  reach  their  assigned  unit  in  3.5  days  (see  Card  Type 
#43). 
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Card  Type  #21 


Unit  personnel  resource  descriptors  include  the  number  on  the  day 
shift  and  the  total  number  on  hand  at  zero  time;  the  difference  is 
assumed  to  be  on  the  night  shift.  In  addition  to  "actual"  values,  the 
user  must  also  enter  the  "target  level"  for  each  of  these  two  factors. 
The  target  levels  may  be  the  same  as  the  actual  levels  or  the 
"authorized"  (MTG&E)  levels,  or  they  may  be  different  from  those  two; 
the  target  level,  however,  may  not  exceed  99,  whereas  the  actual  values 
may  be  as  large  as  320.  The  target  levels  permit  dynamic  estimates  of 
resource  depletion  and  provide  a  basis  for  theater  resource  management. 
Whenever  the  total  number  of  people  of  a  given  type  in  a  unit  changes, 
the  day/total  ratio  of  the  target  levels  is  used  to  apportion  the  new 
force  among  the  two  12-hour  shifts,  subject  to  the  minimum  shift  size 
constraint,  when  entered. 

If  personnel  of  a  given  type  are  organized  into  several  separate 
subgroups,  the  personnel  in  each  group  will  be  identified  by  different 
personnel  type  numbers.  When  personnel  of  a  particular  type  are 
assigned  several  different  designations,  it  is  assumed  that  the  lowest 
numbered  personnel  type  is  associated  with  the  first  subgroup,  or 
company,  and  that  the  next  be  with  the  second,  etc.;  the  highest 
numbered  type  is  assumed  to  be  assigned  to  battalion  level.  Equivalent 
personnel  types  are  identified  as  such  with  the  Type  #45/1  Cards.  When 
personnel  are  designated  for  on-vehicle  tasks  on  the  Type  #5  Cards,  it 
is  mandatory  that  the  lowest  type  number  for  the  specialty  be  specified. 

Combat  engineer  personnel  are  treated  in  a  distinct  manner;  their 
designations  must  be  greater  than  (NOPEOP  -  CEPEO) ,  and  both  shifts  must 
have  the  same  number  of  each  type  of  personnel. 
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Sample  Data:  The  first  card  image  indicates  that  Unit  #1  has  48  Type  #1 
Personnel,  16  Type  #2  Personnel  and  eight  Type  # 3  Personnel;  of  these, 
30,  8,  and  4  are  on  the  day  shift,  respectively.  The  minimum  shift  size 
is  two  for  Types  #1  and  ill,  and  three  for  Personnel  Type  #3. 

The  second  card  image  assigns  six  Type  #30  Personnel  to  each  of  all 
the  units,  since  no  unit  number  is  mentioned.  The  third  card  image 
specifies  that  Unit  # 4  should  be  staffed  with  the  same  numbers  of 
personnel  as  Unit  #3.  Since  no  limits  on  replacement  personnel  are 
specified  with  a  Type  #21/99  Card,  all  personnel  losses  will  be  replaced 
if  so  specified  with  the  Type  #43  Cards. 
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For  each  type  of  support  equipment  to  be  distinguished  in  the 
simulation,  initial  entries  include  the  total  number  in  the  unit,  a 
target  level  for  the  total  number,  and  the  number  that  are  not  in  use  at 
zero  time.  All  three  numbers  would  be  the  same  if  the  unit  were  fully 
stocked  and  all  shop  tasks  were  assumed  to  have  been  worked  off  at  zero 
time  (except  that  the  target  level  may  not  exceed  99). 

If  support  equipment  are  assigned  to  different  company 
organizations,  they  will  be  numbered  differently,  as  with  the  personnel 
data  described  above,  and  the  stocks  for  each  of  the  organizations  will 
be  identified;  the  equivalent  types  will  be  identified  with  the  Type  #46 
Cards . 

Support  equipment  employed  by  combat  engineers  must  have 
designations  greater  than  (NOAGE  -  CEAGE). 


Sample  Data:  The  first  card  image  equips  Unit  #1  with  one  piece  of  Type 
#7  equipment  and  assigns  it  to  Shop  #10.  The  second  card  equips  Unit  #2 
with  the  same  equipments  that  have  been  designated  for  Unit  #1,  up  to 
this  point.  The  third  card  image  equips  all  units  with  fout  Type  #2  and 
one  Type  #3  Equipment.  All  are  available  at  the  beginning  of  the 
simulation.  The  fourth  card  image  changes  the  initial  stocks  of  Types 
#2  and  #3  to  three  and  two,  respectively,  at  Unit  #1. 


Card  Types  #22/66  and  #22/77 


The  specialized  support  equipment  used  for  testing  and  repairing 
electronic  and  electromechanical  equipment--the  ATE  or  Automatic  Test 
Equipment--may  also  be  simulated  in  AURA.  The  manner  in  which  the 
special  characteristics  of  ATE  are  modeled  in  AURA  is  discussed  in 
Section  VII.  Whenever  an  LRU  repair  is  completed  using  an  ATE, 
additional  time  is  allocated  for  maintenance  of  the  station.  This  is 
handled  by  increasing  the  LRU  repair  time  by  a  user-specified 
percentage.  When  that  time  is  over  a  check  is  made  to  see  if  any  piece 
part  needed  for  station  maintenance  was  not  in  stock.  If  so,  the 
station's  residual  capability  to  repair  LRUs  is  estimated  on  the  basis 
of  statistics  that  indicate  how  frequently  each  particular  LRU  repair 
capability  is  lost,  on  the  average,  when  an  ATE  part  is  back-ordered. 

To  do  this  we  imagine  that  each  station  is  divided  into  a  number  of 
sections,  or  "trays,"  one  tray  for  each  type  of  LRU,  and  when  a  part  is 
back-ordered  the  mission  capability  of  each  tray  is  determined  on  the 
basis  of  the  statistical  experience. 

To  organize  the  necessary  input  data,  the  user  must  number  each 
type  of  station  and  each  "tray"  associated  with  each  station.  The 
station  type  numbers  should  be  in  sequence  beginning  with  Type  #1  and 
the  trays  should  be  numbered  consecutively  from  the  first  tray  in 
Station  #1  to  the  last  tray  in  the  last  type  of  station.  The  user  then 
identifies  the  correspondence  between  the  support  equipment  type  and  the 
station  type  on  Card  Type  i;22/t>b,  and  between  the  part  number  and  the 
tray  number  witli  entries  in  the  AISUTA  array  (see  cols.  11-15  on  Card 


Type  #22/66)  and  in  the  TRAY  array  (see  Card  Type  #23/78).  The  #22/66 
and  #22/74  Card  Types  provide  the  rest  of  the  required  data. 

The  entries  for  each  type  of  station  on  Card  Type  #22/66  include 
the  station-type  number,  the  location  in  the  TRAYS  array  of  the  first 
tray  associated  with  the  station,  the  probability  that  a  part  will  be 
unavailable  for  ATE  maintenance  following  each  use  of  that  ATE  station, 
the  order  and  ship  time  to  replace  a  needed  part,  the  increase  (a 
percentage)  in  LRU  repair  time  to  be  used  to  represent  ATE  maintenance, 
and  the  number  of  the  equivalent  support  equipment.  The  probabilities 
that  an  individual  tray  is  affected  by  a  missing  part  are  entered  with 
Card  Type  #22/77. 


Sample  Data-.  The  #22/66  Type  Card  provides  characteristics  for  the  #3 
Type  of  ATE  Station.  The  first  "tray"  associated  with  this  station  is 
located  in  the  ninth  position  in  TRAYS  array.  After  1.31  percent  of  the 
times  this  type  of  station  is  used,  a  piece  part  required  for 
maintenance  of  the  ATE  is  unavailable  and  must  be  ordered;  six  days,  on 
the  average,  are  required  to  obtain  the  needed  component.  The  actual 
repair  time  for  each  LRU  processed  on  station  #3  must  be  increased  by  33 
percent,  to  account  for  necessary  ATE  maintenance  (if  two  or  moYe 
stations  of  the  same  type  are  available  for  cross-checks,  "hot  mock- 
ups,"  etc.,  only  26  percent  additional  time  is  required).  The  equipment 
identification  number  for  the  #3  ATE  Station  is  #18. 

When  a  piece  part  is  required  to  service  the  ATE  and  it  is  not 
available,  the  subsequent  mission  capability  of  the  station  is  affected 
as  specified  by  the  #22/77  Type  Card.  In  this  instance  there  is  a  12.0 
percent  chance  that  the  LRUs  associated  with  Tray  #1  will  not  be 
reparable  if  a  piece  part  is  unavailable  for  ATE  maintenance;  the 
likelihood  for  the  other  trays  varies  from  1.40  percent  for  Tray  #4  to 
16.80  percent  for  Tray  #6. 
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Card  Type  #23 


Ten  distinct  formats  are  used  in  connection  with  Card  Type  #23  to 
permit  the  user  to  either  specify  spare,  part  stock  levels  explicitly,  or 
to  direct  Al'RA  to  generate  exemplar  stock  levels  consistent  with  user- 
specified  parts  procurement  policies. 

Entry  of  Specific  Stock  Levels 

When  the  user  chooses  to  enter  the  stock  levels  himself,  the  first 
of  these  formats  is  used;  entries  include  the  number  of  serviceables 
(i.e.,  available  spares),  the  number  of  reparablcs  or  "bent"  parts,2  and 
the  "normal"  or  authorized  stock  levels.  The  percentage  of  reparables 
that  can  not  be  repaired  at  the  unit--the  NRTS  rate--is  also  entered. 

The  reparable  ("bent")  parts  include  both  those  awaiting  repair  and 
those  undergoing  repair  (if  any);  all  bent  parts  are  presumed  to  be 
stored  in  the  appropriate  shop  and  are  at  risk  to  destruction  if  that 
shop  is  damaged  by  attack.  When  an  on-vehicle  task  is  initiated,  tests 
are  made  to  see  if  a  part  is  broken;  if  it  is,  it  begins  an 
administrative  delay,  after  which  it  is  repaired  in  the  local  shop  or, 
if  it  is  to  be  NRTSed,  it  is  prepared  for  shipment.  The  "nominal  stock 
level"  at  an  operating  unit  is  taken  to  be  the  level  that  is  authorized 
for  the  vehicles  initially  assigned  to  that  unit,  and  it  is  used  with 
certain  of  the  decision  algorithms  for  reaching  judgments  during  the 
simulation  as  to  which  units  have  the  greatest  need  for  parts.  When  a 
unit  has  been  designated  as  a  GSRF,  or  as  the  location  of  the  corps  or 
theater  manager,  the  "nominal  stock  level"  at  that  unit  defines  the 
minimum  stock  level  to  be  maintained  at  that  location;  serviceables 

2  This  entry  normally  is  zero,  with  the  reparable  status  at  zero 
time  being  generated  by  the  ZSHOPS  subroutine;  see  Card  Type  #42. 
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above  this  level  are  "pushed”  to  the  most  needy  unit,  if  that  resource 
management  mode  has  been  selected.  The  number  of  serviceable  parts  of 
any  given  type  may  not  exceed  320  (except  at  the  PWRMS  location),  and 
the  nominal  stock  level  may  not  exceed  250. 

Several  other  Type  # 23  Card  formats  are  illustrated  in  Figs.  5  and 
6.  One  is  used  to  supply  data  on  which  units  may  be  checked  for  a  part 
when  the  simpler  of  two  lateral  supply  doctrines  is  used.  A  Type  #23 
Card  enters  these  data  when  a  "77"  is  entered  in  the  "j"  field.  The 
calling  unit  is  entered  in  columns  6-10  and  the  units  that  may  be  called 
are  entered  in  the  next  five  5-column  fields;  these  five  units  are 
called  in  order.  As  indicated  on  page  63,  an  "68"  or  "99"  in  the  "j" 
field  can  be  used  to  have  the  parts  at  one  unit  duplicated  at  another, 
or  to  enter  the  quantities  of  spare  parts  available  at  depots  for 
replacing  losses.  Card  Type  , •••23/78  is  used  to  identify  the 
corresponding  tray  number  (see  Card  Type  #22/77  and  Section  VII)  for 
those  LRUs  and  SRUs  that  are  repaired  with  ATF.  equipment. 

Pacts  Stockage  Algorithms 

AURA  provides  special  subroutines  that  permit  the  user  to  generate 
the  parts  stock  levels  for  any  unit;  these  are  activated  when  OUTFIT  is 
initialized  on  Card  Type  # 3/3.  The  parts  provisioned  are  for  those 
unscheduled  maintenance  tasks  included  in  the  shop  collections  whose 
occurrence  is  controlled  by  Type  #7  Card  entries.  The  numbers  generated 
are  appropriate  for  a  mobile  combat  spares  kit.  They  do  not,  however, 
make  any  provision  for  the  additional  parts  that  may  be  needed  tor 
repairing  damage  sustained  in  battle  or  in  rear  area  attacks. 

Card  Types  #23/70  and  #23/72  are  used  with  the  parts  generation 
option  to  describe  those  factors  that  define  stockage  policy;  they 
include  the  unit  number  and  kind,  as  well  as  the  type  and  number  of 
vehicles  and  the  nominal  mission  rates,  unit  repair  cycle  times,  order- 
and-ship  times  in  peace  and  war,  and  safety  factors.  Unit  kind 
determines  whether  the  vehicles  operate  from  a  fixed  location  or  from  a 
mobile  one;  KIND  is  1  for  the  former  and  2  for  the  latter.  If  a  GSRF  is 
simulated,  it  must  be.  assigned  its  own  unit  as  well  as  its  own  NRTS 
rates  and  other  policy  factors,  except  that  no  vehicles  are  to  be 
assigned  at  that  location. 
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Fig.  6  —  Auxiliary  vehicle  spare  parts  control  options 
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NRTS  data  for  the  parts  stockage  algorithms  are  entered  using  Card 
Types  23/20x  and  #23/30x  for  each  part  type.  The  23/20x  Cards  define 
that  fraction  that  would  be  NRTSed  at  unit  x  if  there  is  no  GSRF  in  the 
theater,  and  the  #23/30x  Cards  define  the  same  data  for  the  case  in 
which  there  is  a  GSRF.  If  a  part,  LRU,  or  SRU  is  NRTSed  100  percent  of 
the  time  but  first  undergoes  a  normal  administrative  delay  and  then  a 
shop  check,  the  NRTS  value  is  entered  as  100;  if  the  part  is  NRTSed 
immediately  upon  removal,  the  NRTS  rate  should  be  entered  as  101.  When 
NRTS  data  are  not  entered  for  parts,  the  default  value  is  set  to  101, 
i.e.,  parts  for  which  a  NRTS  rate  is  not  entered  will  not  be  subjected 
to  an  administrative  delay  nor  bench-checked  before  shipment.  The  "buy" 
column  on  the  #23/30x  Card  is  currently  not  used;  on  the  #23/20x  Card  a 
"l"  entered  in  the  "buy"  column  prohibits  procurement  of  that  part  type 
for  a  combat  PLL  or  ASL.  The  stockage  calculations  are  explained  at 
greater  length  in  Section  V.l  in  Vol.  I.  If  the  POLICY  array  data 
entered  with  Card  Types  #23/20x  and  #23/30x  are  the  same  at  two  units,  a 
#23/76  Type  Card  can  be  used  to  duplicate  the  data  for  one  unit  at 
another.  (Because  a  #23/76  Card  duplicates  only  that  data  already 
entered,  this  card  can  be  used  to  copy  some,  but  not  all,  POLICY  entries 
from  one  unit  to  another,  by  appropriate  placement  of  the  card  among  the 
entries  for  the  first  unit.) 

When  a  GSRF  is  not  simulated,  the  #23/30x  Cards  may  be  used  to 

provide  the  user  an  option  to  modify  the  NRTS  rates  at  a  specific  time 

during  the  simulation.  This  might  be  desirable,  for  example,  when 
general  support  repair  facilities  become  available  in  the  theater.  To 
use  this  option,  see  the  instructions  for  Card  Type  #31. 

Card  Type  #23/66  provides  unit  cost  data  that  are  used  to  calculate 
combat  PLL  and  ASL  stock  levels  with  an  algorithm  developd  by  Kamins 
that  approximates  the  "marginal  value"  calculation  (when  PM0DE=1);  these 
data  are  also  used  to  compute  the  total  costs  for  all  the  parts  procured 
and  "authorized"  for  each  unit. 

If  the  control  variable  FULL  that  is  defined  on  Card  Type  #3/3  is 

zero  rather  than  one,  a  nominal  number  of  each  type  of  part  that  is 

NRTSed  to  other  locations  will  be  entered  into  the  supply  pipeline  for 
delivery  at  random  times  after  the  simulation  begins.  If  the  user 
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wishes  to  specify  that  the  stocks  that  have  been  procured  are  short  of 
the  computed  allowances,  two  procedures  are  provided.  The  first 
procedure  for  shorting  stocks  reduces  the  estimated  stock  level  for  each 
type  of  part  by  SHORT  percent;  the  second  reduces  the  stock  level  for  a 
portion  of  the  part  types  to  a  value  chosen  at  random  between  K1L0W  and 
(K1L0W  +  K2L0W)  percent.  If  TOOPF.W  is  greater  than  zero,  the  number  of 
part  types  chosen  at  random  to  be  shorted  is  [TOOFEW/IO)  percent  of  the 
part  types;  if  TOOFEV  is  "-l",  the  probability  that  any  part  type  is 
shorted  is  equal  to  that  part's  unit  cost  divided  by  the  unit  cost  of 
the  most  expensive  type  of  part.  These  procedures  may  be  used 
separately  or  together.  If  RAS'DM  is  one,  the  availability  of  each  part 
is  determined  by  a  random  draw;  otherwise  Lhe  shortage  is  the  expected 
value  of  the  shortage. 

Parts  for  battle  damage  repair  can  be  specified  separately,  using 
the  basic  Type  #23  Cards,  or  can  be  provisioned  by  initializing  columns 
41-45  on  Card  Typo  #15/2.  In  addition,  shortages  (overstockage) , 
relative  to  the  numbers  computed  with  these  algorithms  may  be 
represented  by  separately  specifying  negative  (positive)  numbers  of 
parts  witli  the  basic  Type  .'.-23  Cards.  The  user  is  restricted,  however, 
to  entering  at  most  300  specific  stock  levels  for  eacli  unit,  in  addition 
to  those  generated  by  the  stockage  algorithms;  the  part  types  so  entered 
may  be  the  same  as  or  different  from  those  dealt  with  automatically. 


Sample  Data:  The  first  card  stocks  all  units  with  ten  serviceable  Type 
#5  parts.  There  are  no  reparables  at  any  unit  at  the  beginning  of  the 
simulation.  Twenty  percent  of  these  parts  cannot  be  repaired  locally. 
The  target  level  is  12  parts  of  that  kind.  The  second  card  image 
provides  spare  SRUs  for  Part  #5,  which  is  an  LRU  (see  Card  Types  #8). 

Card  Types  #23/20x  and  #23/30x  present  the  NRTS  rates  that  are  used 
when  AURA  generates  spare  parts  stocks.  These  data  indicate  that  in  the 
absence  of  a  GSRF  20  percent  of  Type  #12  Reparables  would  be  NRTSed  at 
Unit  x,  as  well  as  40  percent  of  Type  #13  and  50  percent  of  Type  #15. 
Furthermore,  Type  #13  Parts  would  not  be  procured  for  a  combat  PLL  or 
ASL  (depending  on  Lhe  unit).  The  data  also  indicate  that  all  #13  and 
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#15  Parts  would  be  NRTSed  if  there  were  a  GSRF,  and  80  percent  of  Part 
Types  #12  and  #14  would  be  NRTSed.  Without  a  GSRF  no  #14  Parts  would  be 
NRTSed,  since  the  null  entry  is  taken  to  signify  a  zero  NRTS  rate. 

The  policy  options  that  will  be  used  in  automatically  generating 
parts  levels  are  illustrated  with  the  #23/70  and  #23/72  Cards.  Units  #1 
and  #2  are  both  to  be  treated  as  in-place  units  (KIND  =  1)  that  operate 
48  Type  #1  Vehicles.  The  nominal  peacetime  and  wartime  mission  rates 
are  assumed  to  be  0.8  and  1.2  missions  per  vehicle  per  day;  unit  repair 
times  are  72  and  48  hours  in  peace  and  war,  respectively;  and  the  order 
and  ship  times  are  10  and  20  days  in  peace  and  war.  No  unit-GSRF  travel 
time  is  entered  since  there  is  no  GSRF.  The  safety  factors  (Card  Type 
#23/72)  that  are  to  be  considered  in  computing  stockage  levels  are  1.5 
for  LRUs  associated  with  mission-essential  tasks,  and  0.75  for  those 
that  are  not.  For  SRUs  the  factors  in  these  same  circumstances  are  1.20 
and  0.75. 

Combat  PLLs  or  ASLs  (again,  depending  on  the  unit)  are  specified 
for  Units  #3  and  #4,  KIND  =  2  specifies  these  units  operate  in  the  field 
in  wartime.  Since  PM0DE  equals  1  (see  Card  Type  #3/3)  the  approximate 
marginal  value  logic  is  to  be  used  in  computing  the  stock  for  these 
combat  PLLs  or  ASLs.  The  other  policy  factors  governing  parts 
procurement  for  these  units  are  the  same  as  for  Units  #1  and  #2,  except 
that  fewer  vehicles  are  to  be  covered,  and  the  safety  factor  for  mission- 
essential  LRUs  is  only  1.20. 

The  sample  cost  data  on  the  Type  ^23/66  Card  indicate  that  #11, 

#12,  and  #13  Type  Parts  have  unit  costs  of  $30,000,  $27,500,  and  $600, 
respectively. 

When  parts  are  required  at  Unit  #1,  the  #23/74  Type  Card  indicates 
that  Unit  #2  is  first  asked  if  it  can  fill  the  requirement;  if  not,  Unit 
#3  is  asked.  The  #23/76  Card  indicates  that  the  various  NRTS  data 
entered  with  the  #23/201  and  #23/301  Cards  for  Unit  #1  also  should  be 
applied  to  Unit  #2.  The  #23/78  Cards  specify  which  tray  in  the  ATE 
string  is  associated  with  a  particular  LRU  or  SRU;  this  sample  specifies 
that  Trays  #1,  #10,  and  #5  are  used  with  LRUs  #1,  #2,  and  #3, 
respectively. 
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Card  Types  #24,  #25,  #26  and  #27 

These  cards  specify  the  initial  stocks  of  munitions,  accessories, 
building  materials,  and  POL.  The  "J  =  99"  version  of  each  card  type 
permits  the  user  to  indicate  the  stock  levels  available  for  resupply  for 
whichever  resources  have  resupply  limitations.  Use  of  the  normal 
munitions  type  number  designates  assembled  munitions;  for  unassembled 
munitions,  add  100  to  the  nominal  type  number. 


Sample  Data:  The  first  cards  stock  all  operating  units  with  200  Type  #1 
and  160  Type  # 2  Munitions  that  are  assembled,  and  4000  and  2500  of  the 
same  types  that  are  unassembled. 
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Card  Type  #28 
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These  cards  define  the  one-dimensional  parts-list  (PRTLST)  array. 
These  data  are  used  when  parts  are  to  be  salvaged  from  a  vehicle  too 
badly  damaged  for  repair.  The  numbers  of  all  parts  and  all  LRUs  on  each 
vehicle  type  that  are  to  be  considered  eligible  for  salvage  are  entered, 
as  well  as  the  quantity  of  each  of  these  items  that  are  used  on  the 
vehicle.  If  the  quantity  is  left  blank,  it  is  assumed  that  the  vehicle 
only  uses  one  part  of  that  type.  A  zero  is  used  to  denote  the  end  of 
the  parts  list  for  each  vehicle  type.  The  position  in  the  array  of  the 
first  part  for  each  vehicle  type  is  specified  on  Card  Type  #15.  The 
position  within  the  PRTLST  array  of  the  first  of  the  entries  on  each 
card  is  defined  by  the  value  in  columns  3-5. 
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Card  Type  #29 


These  cards  define  the  order  in  which  on-vehicle  maintenance  tasks 
are  to  be  scheduled.  Tasks  may  be  entered  individually  or  as 
collections  of  work  center  (shop)  activities.  When  a  shop  number  is 
entered,  all  tasks  associated  with  that  shop  number  in  the  SHPTSK  array 
(Card  Type  07)  are  implied.  To  be  distinguishable,  all  numbers  less 
than  31  are  interpreted  as  shops  and  all  others  as  tasks. 

The  order  in  which  tasks  are  carried  out  is  controlled  by  the 
position  of  the  task  and  shop  numbers  on  these  cards.  The  numbers  may 
be  entered  in  any  order;  when  two  or  more  tasks  or  shops  may  be  worked 
at  the  same  time,  the  numbers  are  entered  in  successive  fields;  if  two 
groups  of  tasks  or  shops  may  not  work  on  a  vehicle  simultaneously,  and 
one  must  follow  the  other,  they  will  be  separated  by  a  null  entry  in  a 
field.  The  last  item  is  denoted  by  two  following  null  entries.  Task 
organization  may  be  further  modified  and  controlled  by  the  LISTIN  array 
of  incompatibility  data  (see  Card  Type  019). 

Up  to  five  cards  may  be  used  to  enter  the  task  and  shop  sequence 
for  each  unit-vehicle-type  combination.  A  distinct  set  of  cards  is 
required  for  each  combination,  unless  the  unit  number  is  not  entered,  in 
which  case  all  units  will  function  in  a  common  manner. 


Sample  Data:  These  three  cards  illustrate  how  the  on-vehicle  maintenance 
task  schedule  illustrated  in  Fig.  6  of  Vol.  I  would  be  entered  for  the 
Type  01  Vehicle  at  Unit  01. 
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Card  Type  #30 
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On-vehicle  maintenance  tasks  that  are  not  mission-essential  may  be 
deferred,  and  may  be  worked  off  at  night.  If  there  is  sufficiently  bad 
weather,  a  lull  in  operations,  or  a  stand  down  is  in  effect,  they  may  be 
done  during  the  day  as  well.  The  weather  or  stand  down  status  can  be 
entered  by  unit  and  by  vehicle  type  for  a  65-day  period  with  these 
cards.  Two  groups  of  five  cards  with  14  entries  each  may  be  submitted 
for  each  unit;  the  first  group  is  used  for  the  first  five  vehicle  types; 
the  second  group  is  used  with  the  last  four  vehicle  types.  Each  field 
is  filled  with  ones  or  zeros  (blanks)  to  indicate  the  weather  or  mission 
holds  on  the  nth  day.  The  left-most  column  of  the  first  group  pertains 
to  the  first  vehicle  type  and  the  right-most  column  to  the  fifth  type; 
the  left-most  column  of  the  second  group  applies  to  the  sixth  type  of 
vehicle  and  the  next  to  the  right-most  to  the  ninth.  A  one  signifies 
non-operating  status  for  a  particular  day-unit-vehicle,  while  a  zero 
denotes  no  restriction.  If  no  data  are  entered,  unremitting  operations 
are  presumed  throughout  the  65 -day  period. 


Sample  Data :  Operation  is  interrupted  by  weather  or  command  restriction 
on  only  five  days  at  Unit  #1.  Neither  Vehicle  Type  #1  nor  #2  may 
operate  on  the  3rd  and  17th  days;  the  Vehicle  Type  #1  is  also  held  back 
on  day  20  and  Type  # 2  on  days  8  and  22. 
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COMMUNICATIONS  SYSTEMS  INPUT  DATA 
Card  Type  #31 
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These  cards  permit  the  user  to  define  resource  deliveries  from  the 
CONUS  (i.e.,  outside  the  theater).  The  format  permits  the  user  to 
specify  the  destination  and  Lime  of  arrival  of  each  shipment  from  CONUS, 
and  the  nature  of  the  cargo.  The  destination  and  time  need  be  specified 
only  on  the  first  of  the  cards  defining  the  contents  of  a  shipment, 
since  the  cargos  specified  on  all  subsequent  Type  0 31  Cards  are 
delivered  at  the  same  time  and  place  until  a  new  destination  is 
encountered . 

The  maximum  number  of  items  that  may  be  defined  with  a  single  entry 
is  250  (except  for  munitions  and  accessories,  where  6250  items  are 
permitted),  but  any  number  of  identical  entries  are  permissible  with  the 
same  shipment.  For  POL,  100  units  are  delivered  for  each  unit  entered 
on  this  card  type;  if  the  unit  of  measure  is  tens  of  gallons,  an  entry 
of  50  on  this  card  would  direct  the  delivery  of  5  thousand  gallons-- 
i.e.,  50  *  10  x  100.  (For  POL,  "type"  is  normally  zero;  if  Type  =  100, 
shipment  is  additional  storage  capacity.) 

For  personnel  only,  this  card  type  may  also  be  used  to  withdraw  a 
specified  quantity  of  specialists  of  a  given  type.  To  do  this,  the 
personnel  type  is  entered  as  a  negative  value  as  a  signal  that  the 
quantity  is  to  be  interpreted  as  a  withdrawal. 

This  card  type  is  also  used  to  change  the  NRTS  policies  of  a  unit, 
but  can  only  be  used  when  no  GSRF  is  simulated.  Such  a  change  might  be 
desirable,  for  example,  when  general  support  repair  facilities  become 
available  for  a  division  deployed  to  the  theater.  The  time  to  effect 
the  change  is  signaled  by  delivery  of  a  Type  03250  Part  (Class  03)  to 
the  appropriate  unit.  At  that  time,  the  NRTS  data  that  had  been  entered 
with  Type  023/20x  Cards  are  replaced  with  the  data  submitted  on  the 
023/30x  Card  Types  and  stored  in  the  POLICY  array. 
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Sample  Data :  These  two  cards  specify  that  Unit  //I  is  to  receive  a 
shipment  from  CONUS  at  1700  on  day  5.  Included  are  five  Type  #7 
Personnel,  four  Type  #3  Spare  Parts,  250  unassembled  Type  #4  Munitions, 
50  Type  #11  Accessory,  and  1.2  thousand  gallons  of  POL.  Note  that  the 
arrival  time  and  destination  appear  on  only  the  first  card.  The  third 
card  indicates  that  four  Type  #1  Vehicles  are  to  be  moved  to  Unit  #2  at 
2100  on  day  7. 
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Card  Type  #32 
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These  cards  define  the  daily  intratheater  transportation  schedule. 


The  nominal  departure  Limes  for  .ill  links  in  the  transportation  network 


may  be  specified. 


Sample  Data :  This  card  image  indicates  a  daily  shipment  at  1700  from 
Unit  #1  to  Unit  ?;2  and  a  shipment  every  other  day  at  1400  from  Unit  #1 
to  Unit  #3.  When  shipments  are  not  daily,  the  day  for  the  first 
shipment  is  picked  at  random. 
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Card  Type  #33 
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These  cards,  in  conjunction  with  the  Type  #32  Cards,  describe  the 
intratheater  transportation  system.  For  each  unit  combination  the  user 
may  specify  the  expected  departure  delays  and  their  distributions,  and 
the  transit  times  and  their  distributions.  The  chance  that  a  shipment 
is  lost  (to  enemy  action  or  mines?)  is  also  entered  with  these  cards. 


Sample  Data :  These  data  indicate  that  all  intratheater  shipments  from 
Unit  #1  to  Unit  #2  leave  an  average  of  two  hours  late  and  take  36  hours 
on  the  average  to  reach  their  destination.  The  actual  departure  delay 
and  transit  time  are  determined  by  random  selections  from  Distributions 
#1  and  #2  respectively.  There  is  a  two  percent  probability  that  each 
shipment  is  lost  enroute. 

Note  that  for  shipments  from  Unit  #1  to  Unit  #3  the  arrival 
probability  was  not  entered,  since  the  default  value  is  100  percent,  and 
no  losses  are  expected  along  that  route. 
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Card  Type  #34 


u 

7? 

7! 

Tj 

71 

73 

IT 

m 

IF 

IF 

m 

IF. 

I V 

[HIT 

m 

rr 

ra 

f 7. 

FT 

fU 

F? 

r 

F. 

tr; 

rr 

n 

£ 

F 

fsr 

c 

rr 

si 

S3 

E 

n 

E 

a: 

:c 

E 

m 

e 

c 

E 

E 

El 

-E 

E 

ro 

T 

*T 

s 

£~ 

Q] 

E7 

te. 

C 

£ 

CT 

E 

c 

EZ 

■ 

1 

SIX 

2 

D 

3 

c 

3 

C 

2 

E 

fl 

E 

3 

31 

I 

1 

1 

1 

1 

1 

■ 

1 

1 

II 

fl 

c 

Z 

z 

c 

T 

z 

El 

■ 

i 

1 

1 

1 

a 

c 

i 

IS 

!2 

*1 

B 

2 

1 

1 

■ 

1 

II 

II 

1 

i 

I 

i 

1 

i 

i 

I 

1 

I 

1 

1 

1 

■ 

I 

■ 

■ 

i 

£ 

1 

£ 

* 

i 

1 

1 

1 

s 

X 

\ 

l 

1 

S 

§ 

a 

I 

S 

22 

2 

a 

a 

s 

i 

£ 

i 

22 

a 

i 

5 

i 

3 

«• 

i 

£ 

*3 

8 

a 

I 

s 

5 

1 

1 

£ 

£ 

I 

a 

1 

1 

2 

I 

a 

c 

3! 

32 

3 

i 

1 

1 

■ 

■ 

■ 

1 

I 

l 

1 

3 

i 

L 

□J 

s 

a 

m 

i 

1 

na 

1 

■ 

1 

I 

1 

■ 

■ 

1 

l 

I 

l 

i 

I 

i 

i 

1 

g 

1 

1 

1 

1 

1 

i 

i 

i 

1 

1 

1 

1 

\ 

i 

1 

i 

i 

i 

i 

1 

1 

1 

1 

i 

i 

I 

1 

i 

i 

! 

9 

i 

■ 

■■ 

■ 

■ 

i 

1 

!■ 

i 

1 

( 

1 

■ 

1 

■ 

II 

■ 

■ 

a 

1 

a 

1 

■ 

■ 

1 

8 

§ 

1 

1 

! 

a 

■i 

II 

: 

■ 

■ 

■ 

■ 

I 

i 

2 

1 

1 

I 

2 

11 

i 

i 

1 

i 

i 

I 

I 

i 

ii 

11 

a 

i 

1 

1 

1 

I 

i 

I 

u 

1 

1 

1 

1 

K 

1 

1 

i 

1 

1 

ft 

! 

£ 

1 

i 

These  cards  provide  the  instructions  for  each  unit  for  the 
disposition  of  NRTS  parts.  The  entries  delimit  those  part  numbers  that 
are  to  be  NRTSed  to  other  units.  For  example,  all  parts  numbered  from 
#1  to  the  first  part  number  are  \R';  cd  lo  the  first  unit  listed,  all 
subsequent  part  numbers  up  to  and  including  the  next  part  number  are 
NRTSed  to  the  next  unit,  etc.  If  all  NRTSed  parts  are  to  go  to  a  common 
unit  (i.e.,  a  GSRF)  only  one  entry  would  lie  necessary- - i . e . ,  the  highest 
relevant  part  number  and  the  repair  unit  number.  If  parts  are  to  be 
NRTSed  to  different  units,  the  part  numbers  should  be  organized  into 
contiguous  groups  to  avoid  exceeding  the  SH !  PTO  array  capacity  of  20 
groups.  Parts  to  be  NRTSed  to  COSTS  are  indicated  by  a  unit  number  that 
exceeds  the  maximum  number  of  units  by  one  (i.e.,  MAX B  +  1). 


Sample  Data-.  This  card  indicates  that  whenever  Parts  it  1  thru  •*••600  are 
NRTSed  at  Unit  :•  1  they  are  all  to  bo  shipped  to  CONUS  (i.e.,  MAXR  +  11. 
At  Unit  it 3,  Parts  it  1  thru  .••'13  arc  NRTSed  to  Unit  it  1  and  Parts  .•••14  thru 
#600  are  NRTSed  to  Unit  it 8. 


Jo- A  1 32  686  AURA  (ARMY  UNIT  READINESS/SUSTA INABIU TY  ASSESSOR) 

USER'S  MANUAL  VOLUME  2..IU)  RAND  CORP  SANTA  MONICA  CA 
R  SHISHKO  ET  AL .  JUN  83  RAND/N- 1988MRAL 
(^CLASSIFIED  MDA903-83-C-0047 
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MICROCOPY  RESOLUTION  TEST  CHART 
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Card  Type  #35 


These  cards  provide  the  user  an  opportunity  to  specify  a  time 
different  from  the  default  value  that  is  required  to  cannibalize  a  part. 
For  those  parts  that  have  had  a  cannibalization  time  entered,  the 
nominal  task  time  for  handling  the  relevant  task  will  be  increased  by 
this  time,  when  the  required  part  must  be  acquired  by  cannibalization. 

If  the  entry  is  "-1,"  the  part  may  not  be  cannibalized.  If  the  entry  is 
negative  but  not  "-1,"  the  part  may  not  be  cannibalized  except  when  the 
number  of  vehicles  in  the  unit  that  require  the  part  exceeds  DOCANN;  in 
that  case  the  nominal  task  time  is  increased  by  the  absolute  value  of 
CANNTM  to  account  for  cannibalization. 

If  a  value  is  entered  for  an  SRU,  the  time  required  to  diagnose  and 
replace  that  SRU  is  increased  by  the  entry  if  an  LRU  is  disassembled  to 
obtain  the  required  SRU.  If  no  value  is  entered,  the  default  is  one- 
half  the  nominal  time  for  that  SRU. 


Sample  Data-.  These  data  indicate  that  only  20  additional  minutes  are 
required  to  obtain  a  #1  Type  Part  by  cannibalization,  rather  than  the  36 
minute  default  (i.e.,  the  25  TTU  task  time  for  Task  # 2;  see  Card  Type 
#5).  For  Type  #2  Parts  a  time  of  15  rather  than  30  minutes  is 
indicated.  Part  Type  #3  cannot  be  cannibalized  unless  the  number  of 
vehicles  that  have  this  part  missing  exceeds  five. 
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Card  Type  #36 
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Management  of  theater  resources  may  be  based  upon  imperfect 
information.  These  cards  permit  the  user  to  define  periodic  unit-by¬ 
unit  resource  status  reports  that  may  be  late,  imperfect,  canceled,  or 
lost.  Each  unit  reports  its  current  resource  status  each  day  at  times 
specified  by  the  user.  The  arrival  time  at  "Corps  or  Theater 
Headquarters"  is  controlled  by  the  submittal  time  and  the  uncertain 
transit  time.  The  likelihood  that  any  element  of  the  transmitted  data 
is  received  is  governed  by  the  "item  Loss  Rate,"  and  the  likelihood  that 
the  entire  report  is  lost  in  transit  is  governed  by  the  "Report  Loss 
Rate."  The  transit  times  must  be  such  that  reports  are  received  before 
the  next  one  is  transmitted;  if  this  rule  is  violated,  the  transit  time 
will  be  shortened  appropriately,  and  the  change  will  be  noted  in  the 
output  listing. 


Sample  Data-.  These  data  specify  that  Unit  #1  reports  to  the  control 
authority  at  0230  and  1430  and  that  the  reports  arrive  an  average  of  4 
hours  and  30  minutes  later  (the  variance  is  controlled  by  Distribution 
Type  #1).  There  is  a  three  percent  chance  that  the  report  is  lost  in 
trans it . 
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UNIT  FACILITIES  DATA  AND  ENEMY  AIR/ARTILLERY  ATTACK  DATA 
Card  Type  #37 


Card  Types  #37,  #38,  and  #39  jointly  describe  the  size  of  the 
critical  facilities  in  each  unit,  the  procedures  and  resources  needed  to 
restore  the  facilities  to  an  operational  condition  when  they  have 
sustained  damage,  and  the  relative  priorities  for  repair.  The  sizes  and 
designations  of  the  repair  procedures  for  the  various  facilities  are 
stored  in  the  FACLTY  array,  and  the  resource  requirements  for  each  type 
of  repair  procedure  are  stored  in  the  CERQTS  array.  The  repair  priority 
for  each  facility  is  stored  in  the  CEPRTY  array  and  it  is  mandatory  that 
all  facilities  be  represented  in  that  array,  even  though  some  of  them 
are  not  to  be  considered  for  repair.  A  facility  may  be  restored  to  an 
operational  condition  using  one  repair  procedure,  or  it  may  require  a 
sequence  of  repair  procedures.  The  time  and  resources  required  for  each 
of  these  procedures  is  determined  by  the  extent  of  the  damage  that  was 
sustained . 

The  Type  #37  Cards  describe  the  size  of  the  critical  facilities  in 
each  unit  (other  than  vehicle  shelters)  and  specify  the  types  of 
procedures  that  are  to  be  used  for  repairs  to  each  facility.  Facilities 
(e.g.,  buildings)  of  like  function  in  several  units  should  all  be 
identified  with  the  same  building  number.  Should  a  work  center  (shop) 
that  deals  with  vehicle  maintenance  be  located  in  a  building,  that 
facility  must  be  given  a  "building"  number  identical  to  the  "shop" 
number.  If  the  repair  of  any  of  these  facilities  can  require  an 
additional  repair  procedure  subsequent  to  that  listed  for  the  facility, 
the  data  describing  those  procedures  are  also  stored  in  (otherwise 
unused)  columns  of  the  FACLTY  array;  each  such  listing  defines  the  type 
of  procedure  and  the  effective  "size"  of  the  facility. 

i 

il 
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The  "size"  of  the  facility  is  meaningful  in  the  context  of  the 
repair  requirements  specified  with  Card  Types  #38;  the  time  to  repair  a 
facility  sufficiently  so  it  is  functional  is  defined  in  terms  of  the 
required  reconstruction  (percent  damage  *  size). 

The  work  consigned  to  some  shops  may  in  fact  be  carried  out  at  more 
than  one  location,  and  thus  a  unit's  capacity  for  the  activities 
assigned  to  those  shops  would  not  be  entirely  dependent  upon  a  specific 
facility  not  being  damaged.  When  this  situation  exists,  the  alternative 
locations  for  the  activities  of  any  particular  type  of  shop  are 
designated  with  the  Type  #37  Cards,  along  with  an  indication  of  the  task 
capacity  at  each  location.  When  this  is  done  the  repair  capacity  for 
parts  and  equipment  in  such  a  shop  is  equal  to  the  sum  of  the  capacities 
specified  for  each  of  the  separate  locations  that  remain  undamaged 
following  an  attack.  Maintenance  personnel  and  other  resources  engaged 
in  such  activity  at  the  Lime  of  an  attack  are  assumed  to  be  distributed 
among  the  several  locations  in  proportion  to  their  preattack  repair 
capacities . 


Sample  Data-.  The  first  card  specifies  the  nature  of  the  reconstruction 
that  would  be  required  and  the  size  of  the  facility  for  each  of  three 
facilities  at  Unit  #1;  two  involve  #5  Type  construction  and  one  involves 
#3.  In  addition,  when  the  work  required  using  the  #5  Type  restoration 
procedure  has  been  completed  on  Shop  #1  (Building  #1),  subsequent  work 
may  be  required,  as  defined  by  the  data  filed  for  Building  #51  in  the 
FACLTY  array;  that  work  would  use  the  #7  Type  of  work  procedure. 

The  sample  also  illustrates  the  specification  of  a  distributed  shop 
capacity.  In  this  instance  the  parts  and  equipment  repairs  consigned  to 
Shop  #1  are  distributed  among  Buildings  #1,  #41,  and  #42;  their 
respective  repair  capacities  are  4,  2,  and  1. 
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Card  Type  #38 
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The  resources  required  for  combat  engineering  reconstruction  are 
summarized  on  these  cards.  Each  task  type  defines  the  resource 
requirements  for  a  particular  reconstitution  procedure.  Each  procedure 
is  expressed  in  terms  of  a  level  of  effort  for  manpower  and  support 
equipment;  building  material  requirements  are  assumed  to  be  proportional 
to  the  level  of  damage  that  was  sustained,  and  the  time  required  to 
execute  a  repair  procedure  is  related  to  the  damage  in  a  more  complex 
fashion  as  noted  below.  The  basic  procedures  specified  with  the  Type 
#37  Cards  should  be  followed  whenever  sufficient  resources  exist;  the 
first  alternative  should  be  used  to  specify  a  procedure  that  requires 
fewer  combat  engineer  personnel  and  support  equipment.  (Since  a  unit 
may  have  no  more  than  320  units  of  personnel  of  a  particular  type,  the 
personnel  requirements  for  these  tasks  may  have  to  define  a  unit  of 
personnel  as  several  persons.) 

When  a  facility  may  require  a  sequence  of  two  or  more 
reconstitution  procedures  for  it  to  be  restored  to  operational  status, 
the  time  and  resource  requirements  for  each  procedure  are  determined  on 
the  basis  of  the  damage  reported  in  the  DAMAGE  array  data  for  each 
procedure  or  building  and  the  size  of  that  building  as  defined  by  the 
#37  Type  Cards.  Only  when  all  required  procedures  have  been  executed  in 
sequence  is  the  facility  returned  to  operation. 

The  repair  time  and  material  requirements  entered  on  the  Type  #38 
Cards  should  be  the  requirement  for  one  size-unit  of  reconstruction. 

The  largest  quantity  of  material  that  may  be  entered  for  a  unit-task  is 
320.  The  time  function  relates  the  total  task  time  to  the  unit-task 
time  (as  outlined  in  the  FTIME  subroutine).  It  permits  the  total  task 
time  to  be  expressed  as  the  sum  of  a  startup  time  and  a  damage  dependent 
time.  This  function  is  defined  as: 


I 


1 
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C  =  12  x  p  +  (B  -  l) 
and  the  total  task  time  is: 


T  =  Delay  (B) 


+ 


(Repair  Time) 
(Unit  Damage) 


(Units  of  Damage) 


g(P) 


where 


Delay  (B)  =  0,1,2,3,4,6,8,12,18,24,36,48  hours  for  B  =  1  to  12 

and 

g(P)  =  0.5,  0.75,  0.9,  1.0,  1.1,  1.25,  and  1.5  for  P  =  1  to  7 
Alternative  procedures  are  also  filed  in  the  CERQTS  array. 


Sample  Data :  These  two  cards  indicate  the  primary  and  alternative 
procedures  for  Type  #5  reconstruction  jobs.  The  primary  procedure  uses 
ten  Type  #30  and  eight  Type  #20  Personnel  and  four  pieces  of  Type  #42 
Support  Equipment  and  six  Type  #44.  Thirty  units  of  building  material 
Type  #5  and  60  units  of  Type  #10  are  required  per  unit  of  damage.  The 
time  per  unit  of  construction  is  200  minutes  and  varies  as  a  function  of 
the  amount  of  reconstruction  as  specified  by  function  FTIME  #43;  i.e., 
if  40  percent  damage  were  sustained  by  a  facility  that  is  60  units  in 
size,  the  total  time  for  reconstruction  would  be 


240  +  (200/3)  x  (.40  x  60)  0.9  =  1404  TTU 


or  about  70  hours. 
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Tf  the  alternative  procedure  were  used,  fewer  personnel  and 
equipment  are  required  but  the  time  would  be  increased  (Function  # 56)  to 

360  +  (280/3)  x  (.40  x  60)  =  2600  TTU 

or  130  hours. 
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Card  Type  #39 
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The  order  of  importance  of  the  facilities  and  functions  at  a  fixed- 
location  unit  is  specified  with  these  cards;  the  priority  is  the  same 
for  all  such  units.  For  each  facility  (or  building)  number  that  has 
been  specified  at  a  unit  (including  alternative  facilities  but  exclusive 
of  facility  numbers  used  to  define  a  sequence  of  necessary  tasks),  the 
priority  of  that  facility  must  be  entered  in  this  priority  list,  even 
though  repairs  are  not  contemplated. 

Facility  #36  has  been  set  aside,  (by  program  logic)  with  unique 
dimensional  sensitivity;  the  entry-pair  "36  l"  would  specify  its 
reconstruction  as  the  first  priority  combat  engineering  task;  "2  3" 

would  specify  that  reconstruction  or  reconstitution  of  Shop  #2  was  the 
third  priority  task. 

When  a  unit  has  been  attacked  and  the  total  damage  established  (in 
subroutine  BOMB),  AURA  first  tests  whether  the  combat  engineering 
resources  are  adequate  to  initiate  reconstruction  or  reconstitution  of 
all  damaged  facilities  of  higher  than  or  equal  priority  to  that  of 
facility  CRBLDG.  If  the  resources  arc  available,  all  work  is  started; 
if  they  are  insufficient,  resources  for  the  first  alternative  repair 
procedure  (when  specified),  or  alternatives  thereto,  are  allocated  to 
each  damaged  facility  until  the  combat  engineer  personnel  are  all 
assigned.  By  specifying  fewer  resources  and  longer  times  for  the 
alternative  repair  procedures,  this  use  of  CRBLDG  results  in  the 
available  work  force  being  assigned  to  a  larger  proportion  of  the  more 
critical  tasks. 
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Card  Type  #40 


These  cards  prescribe  the  damage  inflicted  by  enemy  air/artillery 
attacks  on  bivouac  areas.  They  permit  the  user  to  define  the  time  of 
the  attack  and  the  level  of  damage  sustained  by  each  of  the  many  types 
and  several  classes  of  resources.  Such  data  will  need  to  be  developed 
from  a  distinct  set  of  calculations.  The  companion  TSARINA  computer 
model  (derived  from  the  AIDA  airbase  damage  model)  permits  the  user  to 
generate  the  appropriate  data  for  direct  input  into  AURA.  The  procedure 
for  introducing  damage  data  for  multiple  trials,  either  directly  from 
TSARINA  or  with  ' eparate  sets  of  card  images  for  each  trial,  are 
explained  in  the  comments  in  subroutine  INPUTC. 

The  order  in  which  these  data  must  be  entered  is  important.  An 
attack  is  denoted  by  entering  the  time  and  location  of  the  attack  in  the 
"j"  field  and  in  the  next  three  fields.  All  subsequent  Type  #40  Cards 
are  associated  with  the  same  attack  until  an  entry  is  encountered  in  the 
"J"  field. 

The  percent  losses  experienced  by  each  class  and  type  of  resource 
may  be  specified  using  these  cards;  however,  if  the  user  wishes  to 
assume  that  all  members  of  a  given  class  sustain  the  same  level  of 
attrition,  a  type  number  should  not  be  entered;  when  that  is  done,  all 
members  of  that  class  suffer  a  common  loss  percentage.  For  the  first 
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seven  classes  of  resources,  only  the  class,  type,  and  percent  loss  may 
be  entered.  For  vehicles  and  facilities,  additional  loss  rates  may  be 
entered  that  express  the  percentages  of  the  personnel,  equipment,  and 
parts  in  the  facility  that  are  destroyed  by  the  attack.  Entries  for 
these  categories  will  depend  upon  the  user's  assessment  of  the  available 
warning  of  attack  as  well  as  active  and  passive  defenses. 

The  specification  of  damage  and  destruction  to  vehicles  and  of  the 
damage  to  shelters  requires  at  least  three  sets  of  entries.  The  first 
two  are  entered  as  Class  #10  data.  The  "percent  type  lost"  for  "Type 
it l"  is  interpreted  as  the  percentage  of  the  shelters  that  are  not 
designated  for  "special"  duty  that  are  destroyed  in  the  attack.  The 
entries  under  personnel  and  equipment  are  interpreted  as  "the  percentage 
of  the  vehicles  in  those  shelters  that  are  damaged  when  the  openings  are 
unobstructed,"  and  "the  percentage  of  the  unsheltered  vehicles  that  are 
damaged,"  respectively.  The  entry  for  "percent  type  lost"  for  "Type  #2" 
is  interpreted  as  "the  percentage  of  the  vehicles  that  are  damaged  in 
the  attack  that  are  not  reparable."  The  entries  under  personnel  and 
equipment  are  interpreted  as  "the  percentage  of  the  "special"  duty 
shelters  that  are  destroyed"  and  "the  percentage  of  the  vehicles  in  the 
special  duty  shelters  that  are  damaged  when  the  openings  are 
unobstructed" . 

The  final  entries  are  the  Class  «8  data.  The  "percent  type  lost" 
for  "Type  # l"  is  interpreted  as  "the  percentage  of  the  vehicles  that  are 
damaged  in  regular  shelters  when  the  ends  are  blocked"  and  as  percentage 
of  the  personnel,  equipment,  and  parts  associated  with  damaged  vehicles 
that  are  lost.  The  "percent  type  lost"  entry  for  "Type  # 2"  is 
interpreted  as  "the  percentage  of  vehicles  damaged  in  special  shelters 
when  their  ends  are  blocked." 


Sample  Data-.  These  several  cards  specify  the  damage  inflicted  on  Unit 
#3  (operating  from  a  fixed  location)  by  an  attack  at  0538  on  day  2.  The 
first  card  specifies  that  20  percent  of  all  types  of  support  personnel 
(Class  it  1)  and  34  percent  of  all  types  of  munitions  (Class  #4)  are 
destroyed;  all  types  are  affected  since  no  type  is  specified.  The 
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second  card  indicates  that  15  percent  of  Accessory  Type  # 3  and  43 
percent  of  Accessory  Type  #8  were  lost. 

The  third  and  fourth  cards  indicate  that  40  percent,  30  percent, 
and  15  percent  of  Facilities  #5,  #7  and  #3,  respectively,  were  damaged 
and  must  be  repaired  to  restore  the  functions  associated  with  those  shop 
facilities.  The  percentages  of  personnel,  equipment,  and  parts  that 
were  destroyed  in  each  facility  by  the  attack  are  noted.  The  fourth 
card  also  indicates  that  the  unique  facility1  is  closed  and  that  10  hits 
must  be  repaired  to  return  it  to  operation. 

The  last  two  cards  specify  the  damage  sustained  by  the  shelters  (if 
any)  and  vehicles  in  the  unit  at  the  time  of  the  attack.  Note  that  the 
special  data  (Class  #10)  precede  data  for  the  vehicles  (Class  #8).  The 
entries  for  the  Type  #1  special  data  specify  that  10  percent  of  the 
shelters  are  destroyed,  that  40  percent  of  any  vehicles  that  are  only 
partially  sheltered  are  damaged,  and  that  70  percent  of  the  vehicles 
outside  of  shelters  are  damaged.  The  entry  for  the  Type  #2  special  data 
specifies  that  100  percent  of  the  vehicles  that  are  damaged  are  not 
reparable;  since  no  "special"  shelters  have  been  defined  for  this 
illustration,  there  are  no  other  entries  on  this  card.  The  last  card 
specifies  that  15  percent  of  the  vehicles  that  are  sheltered  are 
damaged,  and  that  10  percent  of  the  personnel  and  70  percent  of  the 
equipment  associated  with  the  damaged  vehicles  at  the  time  of  the  attack 
are  lost;  for  those  vehicles  that  are  not  reparable,  92  percent  of  the 
parts  can  not  be  recovered  by  salvage  operations. 

These  various  damage  data  may  be  entered  in  any  order  except  that 
the  special  damage  data  (Class  #10)  must  precede  the  vehicle  damage  data 
(Class  #8). 


5  The  facility  designated  #36  is  interpreted  as  a  runway  for 
aircraft  operations. 
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INITIALIZATION  OF  VEHICLE  AND  SHOP  STATUS 
Card  Type  #41 


These  cards  permit  the  user  to  initiate  the  simulation  with  the 
vehicles  and  shops  in  the  conditions  that  might  be  expected  if  war  were 
to  break  out  following  a  period  of  warning  and  vigilence.  All  vehicles 
are  ready  to  be  sent  on  specified  missions,  fully  loaded  with  the 
preferred  standard  combat  load  and  configuration  for  those  missions.  No 
vehicle  maintenance  tasks,  parts  repair,  munition  assembly,  or  combat 
engineering  tasks  are  in  process,  waiting,  or  interrupted.  These  latter 
conditions  may  be  modified  by  Card  Type  hU 2. 

These  cards  specify  the  numbers  of  each  type  of  vehicle  that  are 
ready  for  each  of  the  several  missions  for  each  unit.  They  must  be 
entered  after  Card  Type  #20,  and  the  units  and  the  vehicle  types  must  be 
entered  in  the  idcnt  ical  order  in  which  they  are  specified  on  Card  Type 

no. 


Sample  Data:  This  card  specifies  that  at  the  beginning  of  the 
simulation  half  of  the  vehicles  on  each  unit  are  assigned  to  one  of  two 
missions;  vehicles  are  configured  for  Missions  #1  and  #2  at  Unit  #1,  and 
for  Mission  #1  and  ?r‘3  at  Unit  #2,  etc.  These  data  must  be  input  in  the 
identical  unit-vehicle  order  used  with  the  #20  Card  Types. 
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Card  Type  #42 


These  cards  can  be  used  in  conjunction  with  Card  Type  #41  to 
initialize  vehicle  maintenance  activity  at  the  beginning  of  the 
simulation.  After  Card  Type  #41  has  been  used  to  specify  that  all 
vehicles  are  ready  to  be  sent  and  that  there  is  no  activity  ongoing  in 
the  shops,  these  cards  will  modify  those  conditions.  To  simulate  the 
existence  of  ongoing  unscheduled  on-vehicle  tasks,  the  user  may  specify 
a  three-part  distribution.  Each  part  is  defined  as  a  fraction  of  a 
given  type  of  vehicle  at  a  particular  unit,  and  a  number  of  tasks;  thus 
one  might  specify  that  10  percent  of  the  vehicles  have  one  unscheduled 
task  to  be  completed,  20  percent  have  two  tasks,  and  5  percent  have  four 
tasks.  At  initialization,  a  random  number  is  drawn  for  each  vehicle  to 
see  if  work  remains,  and  how  much.  If  so,  tasks  are  selected  at  random, 
in  proportion  to  their  nominal  probability  of  occurrence;  when 
initiated,  the  time  remaining  to  completion  is  taken  as  a  random  portion 
of  the  total  task  time. 

The  user  may  also  specify  a  level  of  parts  repair  activity.  Two 
numbers  can  be  input  for  each  vehicle  type  and  unit;  the  first  is  the 
number  of  repair  tasks  to  be  placed  in  the  administrative  delay,  and  the 
second  is  the  number  that  are  placed  in-process  or  waiting.  These 
activities  are  selected  in  proportion  to  their  nominal  probability  of 
occurrence,  and  the  portion  of  the  time  remaining  is  selected  with  a 
random  number. 


Sample  Data-.  This  card  image  indicates  that  Type  #1  Vehicles  at  Unit  #1 
should  be  assigned  ongoing  maintenance  activity  at  zero-time  according 
to  the  distribution  discussed  above.  This  card  also  directs  that  21 
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local  parts  repair  jobs  are  to  exist  at  zero-t ime-- 15  in  the 
administrative  delay  queue  and  six  in  process  or  waiting  for  resources 
to  be  started. 
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Card  Type  #43 


These  cards  permit  the  user  to  simulate  the  requisitioning  and 
resupply  of  resources  that  are  lost  in  combat  or  during  a  bivouac  area 
attack  (either  on  an  operating  unit  or  on  a  rear  DS/GS  maintenance 
unit),  and  parts  that  are  not  reparable  in  the  theater.  For  those 
classes  of  resources  that  are  specified  with  these  cards,  such  losses 
are  replenished  from  CONUS  after  a  delay  that  is  controlled  by  the  mean 
resupply  time  and  the  time  distribution.  The  numbers  that  designate  the 
various  resource  classes  are: 


1  -  Support  personnel 

2  -  Support  equipment 

3  -  Parts 

4  -  Munitions 


5  -  Accessories 

6  -  Building  materials 

8  -  Vehicles 

9  -  Crewmen 


Note  that  the  number  "9"  is  not  used  to  designate  facilities;  this  is 
the  only  exception  to  that  usage  in  AURA.  Also,  POL  is  not  included  at 
this  time 

Whenever  losses  are  suffered  by  any  type  of  resource  of  the  classes 
that  are  entered,  a  resupply  shipment  of  the  same  quantity  and  type  is 
scheduled  to  arrive  at  the  location  that  suffered  the  loss  after  an 
appropriate  delay.  If  the  stocks  available  for  resupply  are  limited, 
the  limits  for  each  type  of  resource  are  specified  with  the  "J  =  99" 
version  of  each  of  the  resource  stockage  cards  (i.e..  Card  Types  #20 
through  #27). 


Sample  Data'.  With  these  illustrative  entries,  support  personnel  that 
are  lost  to  attack  would  be  replaced  in  about  3-1/2  days;  parts  that  are 
lost  or  are  not  reparable  in  the  theater  could  be  requisitioned  from 
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CONUS  with  replacement  expected  in  about  20  days.  Vehicles  lost  in 
combat  or  from  rear  area  attack  would  be  replaced  in  approximately  36 
hours.  In  each  case  the  actual  resupply  time  is  established  with  a 
sample  from  the  #6  Distribution  (i.e.,  about  plus-or-minus  40  percent, 
relative  to  the  mean). 


Card  Type  #44 
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The  probability  that  the  various  unscheduled  on-vehicle  maintenance 
tasks  are  required  after  a  given  mission  are  entered  using  Card  Type  #7. 
The  normal  data  available  for  estimating  these  probabilities,  or 
breakrates ,  are  usually  derived  from  peacetime  experiences  at  low 
training  rates.  Limited  evidence  suggests,  however,  that  the  perceived 
breakrates  in  wartime,  at  higher  activity  levels,  may  not  be  as  high  on 
a  per  mission  basis.  These  cards  permit  the  user  to  reflect  his 
perceptions  of  such  experiences  in  the  simulation  on  a  shop  by  shop 
basis.  The  breakrates  may  be  reduced  (or  increased)  from  the  nominal 
values  for  whichever  vehicle  types  and  shops  are  designated.  Two 
options  are  available;  if  the  control  variable  VBREAK  (Card  Type  #3/2) 
is  zero,  the  entry  is  interpreted  as  the  percentage  of  the  nominal 
breakrate  (as  entered  with  Card  Type  .*;7)  that  should  be  applied. 
Plausible  determinants  might  be  miles  traveled  or  rounds  fired  per 
mission.  If  VBREAK  is  unity  the  entry  is  interpreted  as  the  percentage 
reduction  in  the  breakrate  that  is  experienced  for  each  mission  when  the 
number  of  missions  per  day  per  vehicle  exceeds  one.  If  no  value  is 
entered  (100  percent  of)  the  nominal  values  on  Card  Type  #7  will  apply. 
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Card  Type  #45/1 

When  personnel  and  support  equipment  of  the  same  kind  are  assigned 
to  different  unit  organizations,  it  is  necessary  to  designate  each 
subset  by  a  different  number  in  AURA,  as  illustrated  in  Fig.  7.  The 
Type  #45/1  Cards  provide  AURA  the  necessary  data  with  which  personnel  of 
common  skills  can  be  identified.  Identical  personnel  types  may  be 
assigned  to  up  to  three  company  organizations  and  a  battalion 
organization.  The  personnel  type  numbers  that  are  identified  with  the 
on-vehicle  maintenance  task  requirements  on  Card  Types  #5  and  «6  should 
be  entered  under  "Personnel  Type";  these  personnel  designations  are 
assumed  to  be  available  to  support  the  first  company.  The  AL'RA 
personnel  type  numbers  for  the  same  type  of  personnel  assigned  to  the 
second  and  third  companies  should  be  entered  in  the  next  two  fields; 
those  assigned  at  battalion  level  are  entered  in  the  fourth  field. 

These  numbers,  when  entered  on  this  card  type,  must  appear  in  an 
ascend ing  sequence. 

If  some  personnel  types  are  not  assigned  at  company  level  and  all 
demands  are  met  from  a  common  unit  pool,  the  user  need  enter  the 
personnel  type  number  only  in  the  first  field;  the  same  number  will  be 
entered  automatically  into  the  other  fields.  Contrarily,  any  personnel 
type  that  is  identified  in  the  second,  third,  or  fourth  fields  as  an 
equivalent  type  should  not  be  entered  elsewhere  in  the  first  field. 

These  data  are  used  not  only  to  identify  within  AURA  which 
personnel  types  are  to  be  called  on  when  a  particular  on-vehicle  task 
arises  m  the  second  or  third  company,  they  are  also  used  when  personnel 
of  a  given  type  are  lost  or  gained;  the  program  automatically  cross¬ 
levels  personnel  strengtli  in  the  several  subgroups  so  that  their 
relative  sizes  are  stable,  i.e.,  NOS  strength  per  vehicle  is 
approximately  equal. 


Sample  Data :  The  entries  on  the  first  card  indicate  that  Types  #1  and 
#2  Specialists  are  assigned  to  Company  #1  and  that  their  counterparts  in 
Company  #2  are  Types  #21  and  #22.  There  are  also  some  Type  #2 
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Specialists  assigned  at  battalion  level;  they  arc  designated 
Type  #72.  The  second  card  indicates  that  there  are  no  equivalents  for 
Type  #62  Personnel;  all  such  personnel  can  be  called  upon  for  work  in 
any  company  of  the  battalion. 


f. 
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Card  Types  #45/2  and  #45/3 

Personnel  may  be  cross-trained  to  handle  some  or  all  of  the  tasks 
normally  assigned  to  other  specialists;  others  may  be  trained 
sufficiently  to  assist  the  nominal  specialists.  Card  Types  #45/2  and 
#45/3  provide  the  means  by  which  the  user  can  designate  the  personnel 
types  that  have  been  trained  to  replace  or  assist  various  MOSs .  Up  to 
five  types  of  alternative  specialists  may  be  specified  in  each  category; 
when  personnel  are  organized  into  companies,  only  the  designators  for 
those  in  the  first  company  should  be  entered. 


Sample  Data  tfU5/2:  This  card  indicates  that  Type  #6  and  Type  #7 
Personnel  can  replace  Type  #5  Personnel  and  that  Type  #3  Personnel  can 
replace  the  #2  Types. 


Sample  Data  #45/3:  Types  #5  and  # 7  Personnel  are  trained  to  assist  Type 
#6  Personnel  on  designated  tasks,  and  Types  #2  and  #4  can  assist  #3 
Types . 
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Card  Type  #46 


These  cards  provide  the  same  kinds  of  information  on  support 
equipment  as  are  provided  for  personnel  with  Card  Type  fr45/l.  The  same 
constraints  and  objectives  apply  for  equipment  as  for  personnel. 


Sample  Data:  These  data  indicate  that  a  particular  type  of  support 
equipment  is  assigned  to  both  of  two  companies  and  at  battalion  level; 
they  are  designated  Types  "2,  ■••T2,  and  v22  at  these  locations, 
respect ivo ly . 


09 
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These  cards  permit  the  user  to  specify  the  length  of  the 
administrative  delay  for  each  shop  at  each  unit  for  the  repair  of  both 
parts  and  support  equipment.  These  delays  should  be  used  to  reflect  the 
times  required  to  process  the  necessary  paperwork  and  for  intra-unit 
transportation  as  well  as  the  delays  imposed  by  the  need  to  await  the 
arrival  of  necessary  component  parts,  e.g.,  nuts  and  bolts,  that  are  not 
tracked  in  AURA.  When  a  delay  is  specified  for  parts  or  support 
equipment,  repair  initiation  is  deferred  until  the  delay  has  concluded, 
unless  the  control  variable  EXPED  has  been  set  to  a  value  greater  than 
unity.  In  that  case,  the  delay  will  be  reduced  to  1/EXPED  times  the 
nominal  value  when  the  unit  has  no  serviceables . 


Sample  Data :  The  sample  indicates  a  48-hour  parts  repair  delay  at  the 
first  three  shops,  and  60  hours  at  Shops  #4,  #5,  and  #15;  the  actual 
delays  are  all  selected  from  a  Type  #6  Distribution.  For  equipment  the 
nominal  delays  are  72  hours  at  all  shops  except  #6  and  #10,  where  they 
are  only  36  hours. 
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Card  Type  #48 
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Since  the  environment  and  procedures  at  a  GSRF  (or  DISCOM)  could 
differ  substantially  from  the  conditions  at  an  operating  unit,  this  card 
is  provided  to  permit  the  user  to  specify  a  percentage  by  which  the 
times  for  all  the  parts  repair  jobs  at  a  given  shop  will  be  modified 
when  they  are  conducted  at  a  GSRF. 
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Card  Type  #49 
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These  cards  permit  the  user  to  change  many  of  the  key  control 
variables  or  array  elements  at  a  time  subsequent  to  the  initiation  of 
the  simulation.  The  mechanism  for  accomplishing  these  changes  is 
managed  in  subroutine  MODIFY,  where  the  specific  kinds  of  changes  to  be 
used  must  be  encoded.  The  changes  supported  with  the  current  version  of 
AURA  include  NTYPE ,  PRINT,  FILLAC,  SLEEP,  REST,  HURRY,  etc.;  the 
complete  list  of  20  variables  can  be  noted  in  that  subroutine.  Each 
change  type  number  is  the  label  in  the  code  for  that  variable  divided  by 
10.  By  changing  HURRY,  the  user  can  vary  task  efficiencies  in  a 
stepwise  fashion  over  time  for  different  task  types  and  at  different 
units.  The  procedures  for  using  this  feature  can  be  inferred  from  the 
comments  in  the  code  at  label  210  in  subroutine  MODIFY. 

These  time-dependent  change  data  are  stored  in  the  CHANGE  heap; 
entries  may  be  introduced  exogenously  during  initialization  using  Card 
Type  #49 ,  or  adaptively  during  the  course  of  the  simulation,  with  a  call 
to  the  NEWVAL  entry  point  in  subroutine  MODIFY.  Several  changes  may  be 
entered  with  each  card;  data  ir'-lude  the  day  and  hour  for  the  change,  as 
well  as  the  type  of  change  and  the  new  value.  As  illustrated  in  the 
MODIFY  subroutine,  array  elements  may  also  be  changed  in  this  fashion  by 
"packing"  information  regarding  the  appropriate  array  element  with 
either  the  "type"  entry  or  the  "value"  entry. 

AURA,  as  currently  written,  provides  a  few  illustrative 
possibilities  for  adaptive  control  of  the  simulation  in  subroutine 
MODIFY.  Furthermore,  subroutine  ADAPT,  which  is  called  at  midnight  each 
day,  provides  a  convenient  context  within  which  to  introduce  the  logic 
necessary  to  schedule  changes  that  would  subsequently  be  activated  with 
a  call  to  NEWVAL  in  MODIFY. 
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Sample  Data :  The  sample  entries  indicate  that  (1)  the  value  of  the 
variable  PRINT  (Change  Type  #4)  is  to  be  changed  to  2  at  the  beginning 
of  the  seventh  day,  and  (2)  the  value  of  REST  (Change  Type  #8)  is  to  be 
changed  to  60  minutes  (20  TTU)  at  the  beginning  of  the  tenth  day. 
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INPUT-DATA  LIST  CONTROL  CARD 

The  termination  of  the  basic  input  data  entered  with  Card  Types  #1 
through  #49  inclusive  is  denoted  with  a  blank  Card  Type  #99.  This  card 
is  followed  immediately  by  the  Input-Data  List  Control  Card.  It 
controls  which  of  the  input  data  are  to  be  reprinted  as  they  are  stored 
in  the  various  storage  arrays  after  program  initialization.  A  "l"  in 
any  column  between  5  and  45  inclusive  (except  cols.  7,  11,  29,  32,  33, 
34),  will  direct  a  listing  of  the  data  that  were  entered  using  card 
types  of  the  same  number;  all  time  data  will  have  been  converted  to  AURA 
time  units  (TTU)  and  in  some  cases  the  data  will  have  been  packed  or 
repacked.  The  control  data  entered  with  Card  Types  #1  through  #4  are 
summarized  on  the  first  page  of  the  output. 

The  Type  #50  Cards,  which  input  the  mission  demand  data,  will 
follow  this  card. 
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MISSION  DEMAND  DATA 
Card  Type  #50 

Several  different  types  of  mission  demand  data  are  entered  with 
this  Card  Type--unique  demands,  periodic  demands,  and  overwatch  levels, 
as  well  as  changes  in  these  demand  data;  several  of  these  are 
illustrated  in  Fig.  8.  To  limit  the  size  of  data  storage  arrays,  AURA 
permits  the  mission  demands  to  be  read  at  user  controlled  intervals,  as 
will  be  explained. 

The  user  may  specify  mission  demands  for  specific  days  and  at 
specific  times,  or  he  may  specify  a  set  of  mission  demands  that  repeat 
every  day,  each  with  a  specified  probability  and  at  times  selected  from 
a  specified  (.10  hour  maximum)  Lime  block.  Furthermore,  up  to  31 
identical  missions  may  be  demanded  within  the  same  time  block  with  a 
single  periodic  demand  entry.  The  option  for  recurring  or  periodic 
mission  demands  provides  the  analyst  a  convenient  means  of  specifying  a 
demand  pattern  that  varies  randomly  from  day  to  day,  as  might  be 
expected  in  a  wartime  environment.  The  user  may  also  employ  any 
combination  of  these  options.  The  periodic  mission  demands  must  each  be 
numbered  by  the  user  in  the  J-field  (i.e.,  cols.  3-5);  the  likelihood, 
in  percent,  that  the  mission  is  demanded  on  any  given  day  is  entered  in 
columns  28-30. 

The  number  of  vehicles  that  arc  to  be  placed  on  overwatch  or  in 
reserve  are  also  specified  with  Card  Type  (150;  in  this  case  the  "Start 
Time"  is  interpreted  as  the  time  at  which  the  overwatch  requirement  is 
to  start.  These  cards  are  distinguished  by  a  ”-l"  entry  for  "Hours 
Notice";  the  demands  are  not  periodic  but  rather  persist  until  changed. 

Mission  priority  is  denoted  with  an  integer  from  one  to  six 
inclusive;  priority  number  one  is  the  highest  priority.  Priorities  two 
and  four  are  reserved  to  denote  demands  for  vehicles  that  have  been 
placed  on  overwatch  or  reserve.  Demands  for  dispatching  reserve 
vehicles  are  presumed  to  occur  without  advance  notice  (i.e.,  the  "Hours 
Notice"  entry  should  be  zero). 

Certain  other  conditions  or  constraints  are  noted  in  the  format 
illustration.  If  the  minimum  mission  size  and  the  final  unit  are  not 
entered,  they  are  automatically  set  equal  to  the  maximum  mission  size 
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Fig.  8  —  Mission  demand  data 
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and  the  initiating  unit,  respectively.  The  desired  start  time  is 
entered  in  hours  and  minutes  (e.g.,  1545  for  1545  hours). 

Several  sets  of  mission  demand  data  may  be  treated  as  a  single 
composite  mission,  in  which  all  elements  must  satisfy  at  least  the 
minimum  mission  size  requirement,  or  the  entire  mission  will  be  canceled 
and  all  ready  vehicles  placed  in  the  spare  queues.  With  this  feature 
the  user  may  demand,  for  example,  four  tanks  from  one  unit,  four  armored 
personnel  carriers  from  another  unit,  and  four  self-propelled  howitzers 
from  a  third  unit.  To  demand  a  composite  mission,  card  images  must  be 
sequential,  and  all  but  the  first  card  image  will  be  identified  with  200 
for  the  "demand  probability."  Up  to  six  submissions  may  be  combined 
into  a  single  composite  mission  with  up  to  50  vehicles,  in  total.  All 
elements  of  a  composite  mission  must  be  scheduled  for  the  identical 
start  time  and  the  several  card  images  defining  the  composite  mission 
must  be  entered  one  after  the  other.  The  set  of  card  images  defining  a 
composite  mission  may  specify  either  a  unique  or  periodic  demand.  If 
they  are  a  periodic  demand,  the  time-block  feature  and  multiple  demand 
feature  normally  available  with  such  types  of  demand  may  not  be  used. 

It  is  sometimes  of  interest  to  be  able  to  simulate  a  "go-when- 
ready"  demand  policy.  This  may  be  done  by  using  periodic  demand  cards 
to  specify  several  missions  of,  say,  12  vehicles  (with  as  few  as  one 
acceptable)  every  hour  and  also  by  permitting  vehicles  to  be  started  up 
to  an  hour  late.  Whenever  a  vehicle  completes  maintenance  during  the 
operating  day,  there  will  be  a  demand  outstanding  that  it  can  fill. 

Mission  demand  data  are  entered  at  the  time  of  program 
initialization  and  up  to  once  a  day  thereafter.  Those  data  to  be  read 
at  program  initialization  time  are  terminated  with  a  Card  Type  7/99, 
specifying  the  first  day  for  reading  subsequent  data  in  columns  3-5.  If 
a  day  greater  than  one  is  entered  in  that  field,  the  periodic  missions 
will  be  rescheduled  for  the  second  day  and  other  days  before  the  one 
named;  new  mission  data  are  read  each  day  at  2000  hours. 

Another  special  feature  permits  a  mission  to  be  reduced  or  canceled 
before  it  has  been  initiated,  thereby  simulating  the  effects  of  such 
changes.  This  feature  is  actuated  when  a  negative  mission  size  is 
listed  for  a  mi.sion.  When  that  is  done  the  entry  for  the  "number  of 
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hours  notice"  is  interpreted  as  the  number  of  hours  before  the  mission 
that  is  to  be  reduced  or  canceled.  Thus,  if  there  is  a  demand  for  12 
vehicles  at  1545,  and  a  demand  of  -4  vehicles  of  the  same  type,  for  the 
same  mission,  and  from  the  same  unit  at  1345  (with  a  two  hour  notice), 
then  the  1545  mission  demand  is  reduced  from  12  to  eight  vehicles  at 
1345,  and  the  minimum  permissible  size  for  that  mission  is  the  value 
entered  after  the  value  -4. 

Whenever  new  mission  data  are  read  in  (on  the  day  specified  by  the 
preceding  data  terminator  card)  both  unique  and  periodic  missions  may  be 
demanded.  As  before,  periodic  missions  will  be  numbered  (cols.  3-5)  and 
whenever  a  number  previously  used  is  entered,  the  new  data  replace  the 
old.  Each  new  set  of  mission  data  is  terminated  with  a  Card  Type  //99; 
the  number  of  days  before  the  next  entry  must  be  placed  in  columns  3-5. 

AURA  is  now  dimensioned  so  that  400  missions  may  be  scheduled  in 
any  24  hour  period  and  160  periodic  missions  may  be  stored  at  any  one 
time. 

Sample  Data-.  These  several  cards  illustrate  the  various  mission  demand 
options.  The  first  card  specifies  a  demand  calling  for  eight  Type  #2 
Vehicles  (six  minimum)  to  be  sent  from  Unit  #2  at  1915  on  day  7;  they 
are  to  be  configured  for  Mission  Type  #3,  which  is  a  top  (#1)  priority 
mission.  The  demand  is  received  at  1315  (i.e.,  1915-0600)  on  day  7. 
Since  no  final  unit  is  noted,  the  vehicle  remains  attached  to  the  same 
unit . 

The  second  card  indicates  a  mission  that  is  to  be  sent  from  Unit  #3 
with  a  75  percent  probability  each  day  at  0630.  Six  Type  (/I  Vehicles 
(five  minimum)  are  to  be  prepared  for  a  Type  #1  Mission;  the  demand  for 
this  third  priority  mission  is  received  in  the  evening  at  2030  (10  hours 
before  mission  time). 

The  third  card  specifies  that  as  of  0800  on  the  fourth  day,  four 
Type  01  Vehicles  will  be  maintained  in  reserve  for  Mission  Type  #2  at 
Unit  01.  This  second  priority  requirement  stands  until  changed. 

The  next  three  cards  jointly  specify  a  composite  mission  to  be  made 
up  of  three  platoons  of  four  vehicles  each  from  Units  01,  02,  and  03  to 
be  started  at  noon  of  the  fourth  day.  The  vehicle  types  and  missions 


118  - 


vary  from  platoon  to  platoon.  The  demand  is  received  at  0400  on  the 
fourth  day  and  the  entire  mission  must  be  canceled  if  all  12  vehicles 
are  not  ready;  to  enhance  the  likelihood  that  cancellation  will  not  be 
required,  top  priority  (1)  is  assigned  to  this  composite  mission. 

The  seventh  card  exercises  the  mission  demand  revision  option. 

This  card  specifies  that  at  1715  on  Day  7  an  order  is  received  to  reduce 
the  mission  size  of  a  mission  two  hours  later,  by  four  vehicles  (new 
minimum  is  three).  Since  the  mission  demand  on  the  first  card  is  for 
the  same  unit,  vehicle  type,  mission,  and  priority  and  is  at  the  correct 
time,  it  is  reduced  to  four  vehicles  (i.e.,  8  -  4). 

The  next  card  specifies  a  recurring  demand  on  Unit  #1;  a  demand 
without  warning  for  two  Type  #1  Vehicles,  configured  for  Mission  Type 
#2,  to  be  dispatched  immediately  at  0930.  This  demand  occurs  with  50 
percent  probability  each  day.  These  vehicles  will  be  drawn  from  the 
reserve  force  generated  by  the  requirement  specified  on  the  third  card, 
if  they  are  available. 

The  next  to  last  two  cards  specify  recurring  demands  for  four  two- 
vehicle  missions  from  Unit  ?;2  and  from  Unit  it 3;  these  missions  are  to  be 
started  each  morning  at  times  selected  at  random  between  0800  and  1030. 
In  all  cases  the  demands  are  received  only  two  hours  before  mission 
time.  At  Unit  ?;2,  Type  pi  Vehicles  are  to  run  Type  it 2  Missions.  A 
priority  of  3  is  specified  for  all  of  these  missions.  The  missions  will 
not  be  attempted  unless  both  vehicles  are  ready. 

The  last  card  also  specifies  a  recurring  demand,  but  it  differs 
from  all  other  illustrations  in  that  no  unit  is  specified.  This  type  of 
demand  is  permitted  only  when  the  control  variables  STATE  and  SELECT 
have  both  been  initialized  to  one  or  greater.  When  that  has  been  done, 
AURA  will  assign  these  demands  for  four  three-vehicle  missions  between 
2000  and  2100,  to  the  unit  best  able  to  handle  them.  They  may  be 
assigned  to  one  or  more  units,  depending  upon  their  capabilities. 
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Card  Type  #60 


Unit-to-unit  shipping  schedules  may  be  changed  at  the  same  time 
that  changes  are  made  in  mission  data  by  entering  #60  Type  Cards  along 
with  #50  Type  Cards;  in  fact,  only  Type  #60  Cards  need  be  entered.  The 
time  for  entering  such  changes  is  controlled  with  Card  Type  #99  as 
described  with  the  Type  #50  Cards. 

To  change  any  particular  schedule,  or  to  add  or  eliminate  a 
schedule,  it  is  necessary  to  know  the  total  number  of  schedules  already 
entered  with  the  #32  Card  Types,  and  the  position  of  any  schedule  that 
ia  to  be  changed  within  that  overall  number.  The  order  of  data  entry  is 
(1)  rank  order  position  of  schedule  that  is  changed/added/deleted,  (2) 
departure  point  (unit),  (3)  destination  (unit),  and  (4)  departure  hour. 
If  a  schedule  is  to  be  added,  its  rank  order  position  must  be  one 
greater  than  the  existing  number  of  schedules.  Two  sets  of  data  may  be 
entered  with  each  Card  Type  #60. 

If  the  departure  frequency  is  entered  as  a  zero,  no  further 
shipments  are  planned  for  that  schedule,  unless  subsequently  revitalized 
with  another  Type  #60  Card. 


Sample  Data :  These  entries  indicate  that  the  original  shipment  schedule 
from  Unit  #1  to  #3  (entered  second  on  the  #32  Type  Cards)  is  to  be 
changed  from  every  other  day  to  daily. 
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XX.  DATA  BASE  FOR  SAMPLE  PROBLEM 


The  entries  used  in  the  explanations  of  the  data  input  procedures 
in  Section  XIX  were  selected  to  illustrate  some  of  the  more  complex 
features  of  AURA.  The  sample  data  base  to  be  used  here  will  be  much 
simpler,  involving  only  three  units  of  battalion  size  operating  a  single 
type  of  hypothetical  armored  vehicle,  and  supported  by  one  rear  area 
maintenance  unit  (e.g.,  a  FAST)  for  longer  repair  tasks  than  are 
tolerable  in  forward  locations. 

DICTIONARIES 

One  of  the  first  tasks  in  developing  an  AURA  data  base  is  to  create 
dictionaries  for  the  various  classes  of  resources  to  be  simulated. 

These  provide  a  bridge  from  the  type  numbers  within  each  resource  class 
(usually  one  or  two  digits)  to  the  nouns  that  are  recognizable  to  the 
nonmodellor.  Below  we  show  the  dictionaries  for  the  data  base 
illustrated  in  this  section. 

The  identifying  number  assigned  to  each  resource  type  is  arbitrary 
and  is  selected  by  the  user.  The  only  restrictions  are  that  the  numbers 
selected  must  be  no  larger  than  the  relevant  storage  arrays,  and  the 
designators  for  combat  engineer  personnel  and  support  equipment  should 
be  larger  than  ( NOPEOP  -  CEPEO)  and  (NOAGE  -  CEAGE ) ,  respectively.  In 
the  present  illustration  the  PEOPLE  array  is  dimensioned  for  200  types 
of  personnel,  and  ten  are  reserved  for  combat  engineer  type. 

Consequently  any  type  number  up  to  100  may  be  used  for  personnel  who  are 
not  combat  engineers.  When  two  or  more  designations  are  used  for  the 
same  MOS  assigned  to  two  or  more  subgroups  (e.g.,  companies  or 
batteries),  the  lowest  numbered  designation  must  be  assigned  to  the 
first  subgroup  as  shown.  (See  instructions  for  Card  Type  021  and  Card 
Type  #45/1.)  This  rule  applies  to  support  equipment  as  well. 
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Table  2 

EXAMPLE  RESOURCE  DESIGNATOR  DICTIONARIES 


Personnel 

Type 

Description 

Equipment 

Type 

Description 

Parts 

Type 

Description 

1 

Tracked  Veh.  Mech. 

1 

Recovery  Veh. 

1 

Power  Pack 

2 

Electrician 

2 

A-Frame 

2 

Engine 

3 

Armament  Mech. 

3 

Transmission 

4 

Recovery  Veh.  Driver 

4 

Radiator 

5 

Crewman 

5 

Alternator 

28 

Hydraulic  Pump 

29 

Actuator 

DATA  ORGANIZATION 

The  simplest  and  least  error-prone  method  of  organizing  data  for  an 
AURA  simulation  is  to  order  the  data  input  card  images  by  their  Card 
Type  numbers.  Similarly,  the  large  data  collections  that  define  the 
various  tasks  are  also  best  organized  by  ordering  them  by  their  task 
number;  thus  the  on-vehicle  tasks  defined  by  Card  Types  #5  would  be 
ordered  by  the  task  number  appearing  in  columns  3-5.  It  is  much  easier 
to  locate  and  check  data  entries  when  they  are  organized  in  this  manner. 

There  are  few  mandatory  rules  regarding  the  order  of  data  entry, 
but  what  rules  there  are  must  be  observed;  they  are: 

•  The  first  card  in  the  input  card-image  deck  is  either  blank  or 
has  "l"s  in  the  columns  corresponding  to  the  card  types  that 
are  to  be  listed  at  entry  time. 

•  Card  Types  #1  through  #4  must  be  entered  in  numerical  order  and 
before  any  other  card  types.  (Note  the  special  rules  regarding 
columns  3-5  of  Card  Type  #1  and  TEST  on  Card  Type  # 2.) 
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•  Card  Types  #20,  #41,  and  #42  must  be  entered  in  numerical 
order.  (Note  special  rules  for  entering  vehicle  missions  on 
Card  Type  #41 . ) 

•  When  resource  data  are  not  entered  specifically  for  each  unit, 
but  take  advantage  of  the  convenience  features  described  for 
these  data,  the  resultant  data  base  depends  on  card  order. 

•  The  mission  demand  data  are  entered  using  the  #50  Card  Types 
after  all  Card  Types  #1  through  #49  are  entered.  The  #50  Cards 
are  preceded  by  a  Type  #99  Card  and  a  card  that  controls  input 
data  listings.  The  Type  #50  Cards  are  followed  by  a  Type  #99 
Card  specifying  the  data  for  the  next  addition  or  modification 
to  the  mission  or  intratheater  transportation  schedules. 
Subsequent  changes  to  these  schedules  are  specified  with 
additional  Type  #50  Cards  followed  by  another  Type  #99  Card 
specifying  the  number  of  days  that  should  elapse  before  the 
next  inputs  are  to  be  read,  if  any. 

..  Fi-gures  9  through  12  present  the  data-entry  card-images  specifying 
the  sample  problem  discussed  in  this  section.  They  are  presented  here 
as  they  would  be  organized  for  submission  to  the  computer.  The 
remainder  of  this  section  outlines  the  nature  of  the  sample  problem  this 
data  base  is  intended  to  address. 

CONTROL  VARIABLES 

Card  Type  #1  designates,  on  Fig.  9,  five  trials  of  a  15-day 
simulation.  Three  operating  bases  with  one  vehicle  type  are  to  be 
simulated  (NBASE  =  4  and  NTYPF,  =  1);  crews  are  to  be  monitored  (CREWS  = 
1),  and  no  munitions  are  to  be  assembled  (BUILD  =  0). 

Theater  resources  are  not  to  be  monitored  centrally  (AURA  =  0)  and 
spare  parts  arriving  from  CONUS  will  not  be  managed  centrally  (C0NSIG  = 
010)  using  CMODE  =  0.  Because  no  personnel  or  support  equipment  are 
provided  at  the  highest  numbered  unit  (Unit  #8--see  Card  Types  #21  and 
#22),  there  can  be  no  centralized  parts  repair.  The  attack  damage  data 
that  will  be  entered  were  not  generated  by  TSARINA  (AIDA  =  0). 
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Fig.  9  —  Sample  problem  data  set  (cards  1-5) 
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Fig.  10  —  Sample  problem  data  set  (cards  5-18) 
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Fig.  11  —  Sample  problem  data  set  (cards  20-28) 
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Fig.  12  —  Sample  problem  data  set  (cards  29-50) 


127 


Card  Type  #2/1  calls  for  substantial  daily  output  (PRINT  =  14)  with 
cumulative  shop  statistics  to  be  printed  every  five  days  (CJMSTA  =  5). 
The  first  ten  entries  on  Card  Type  # 2/2,  which  control  the  several 
random  number  streams  that  may  be  repeated  exactly  on  each  trial,  keep 
the  same  sequence. 

Card  Type  #3/1  indicates  that  combat  operations  will  be  conducted 
from  three  forward  operating  units,  and  that  unscheduled  maintenance 
tasks  are  to  be  deferred  when  they  are  not  essential  for  the  designated 
mission  (POSTPN  =  1),  but  are  not  to  be  forgotten  (IGNORE  =  0).  Battle 
damaged  tasks  are  to  be  completed  prior  to  other  unscheduled  maintenance 
(CONCUR  =  0).  Parts  may  be  cannibalized  from  vehicles  that  already  have 
a  part  missing,  whether  or  not  a  reparable  of  the  type  required  is  at 
the  unit  (CANMOD  =  2).  Cannibalization  may  not  remove  over  20  parts 
from  any  vehicle  (MXHOLF.  =  20). 

Card  Type  # 3/2  designates  many  of  the  policies  that  are  to  be  used 
to  manage  the  transfer  of  vehicles.  Whenever  a  vehicle  is  transferred 
to  the  FAST  for  mandatory  maintenance,  all  other  required  tasks,  as  well 
as  all  deferred  tasks,  are  scheduled  for  completion  at  the  FAST  as  well 
(J0BC0N  =  3). 

Card  Type  #3/3  designates  that  the  parts  are  to  be  initialized  at 
the  units  designated  with  the  #23/70  Type  Cards  (OUTFIT  =  1)  and  that 
combat  PLLs  are  to  be  provisioned  so  as  to  provide  30  days  of  supply. 
(PMODE  =  0).  Card  #4/1  specifies  that  crewmen  must  have  a  minimum  of  six 
hours  of  sleep  each  day  and  that  they  must  be  able  to  rest  for  at  least 
30  minutes  between  missions.  The  combat  maneuvering  is  expected  to  be 
largely  completed  by  2100Z  each  day  (ENDAY  =  21),  and  deferred 
maintenance  may  be  initiated  after  that  hour.  To  initiate  such 
maintenance,  the  nominal  task  completion  time  must  be  no  later  than 
0400Z  (LSTT0D  =  400),  at  which  time  munitions  loadings  that  have  been 
delayed  should  be  initiated;  otherwise  delayed  loadings  should  start  at 
0015Z  (LOADTM  =  015).  Two  hours  overtime  (OVERTIM  =  120)  is  permitted 
if  it  is  required  to  complete  unscheduled  maintenance  tasks  or  munitions 
assembly  jobs.  No  parts  may  be  cannibalized  from  any  vehicle  that  has 
an  estimated  ready-to-go  time  within  eight  hours. 
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Card  Type  #4/2  indicates  that  no  projections  of  each  unit’s  mission- 
generation  capability  will  be  prepared  and  transmitted  to  th°  corps  or 
theater  manager  (STATE  =  0). 

TASK  DESCRIPTIONS 

The  most  difficult  data  preparation  chore  for  AURA  is  developing 
the  data  that  define  what  jobs  need  to  bo  done,  how  often,  what 
resources  are  required  for  their  accomplishment,  and  how  long  they  would 
be  expected  to  take.  Card  Types  #5  (#6),  #8  (#9),  #10,  #11,  #13,  #14, 
and  #38  are  used  to  enter  those  data  for  unscheduled  vehicle 
maintenance,  parts  repair,  equipment  repairs,  munitions  assembly, 
reconfiguration  and  loading,  and  for  the  combat  engineer  facility 
restoration  tasks. 

Fifty-three  on-vehicle  maintenance  tasks  (Card  Type  #5)  are 
illustrated  in  Figs.  9  and  10;  most  are  unscheduled  tasks,  but  one  deals 
with  refueling  and  one  with  daily  inspection.  Tasks  #31,  34,  37,  42, 

49,  and  52  lead  into  task  networks.  No  alternative  task  procedures  are 
def ined . 

MISSION  AND  MUNITIONS  DATA 

The  standard  combat  loads  for  the  three  missions  to  which  Vehicle 
Type  #1  can  be  assigned  are  specified  with  Card  Type  #12  in  Fig.  10. 

SCL  #1  1  s  the  preferred  load  for  all  three  missions.  Resource 
requirements  for  loading  the  munitions  are  specified  with  Card  Type  #13. 
Card  Types  #15  and  #16  specify  the  various  data  that  define  operational 
factors  for  Vehicle  Type  #1  and  for  the  vehicle's  three  missions  that 
make  up  the  SOC  against  which  these  units  are  being  measured.  Special 
unit  information,  shift  schedules,  and  task  incompatibility  data  are 
entered  on  Card  Types  #17,  #18,  and  #19. 

UNIT  RESOURCES 

The  resources  available  at  each  unit  at  the  beginning  of  the 
simulation  are  defined  with  Card  Types  #20  thru  #27.  When  the  resources 
at  two  or  more  units  are  the  same,  in  part  or  in  total,  the  features 
described  in  Section  XIX  can  be  used  to  reduce  the  required  number  of 
card  images. 
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The  initial  numbers  of  vehicles  and  crews  allocated  to  each  unit 
are  specified  in  Fig.  11  on  the  Type  #20  Cards.  Thirty-eight  Type  #1 
Vehicles  and  40  crews  are  at  each  of  the  three  forward  operating  units. 
Their  initial  mission  configuration  is  shown  on  the  Type  #41  Card  in 
Fig.  12  as  36  ready  for  Mission  #1  and  the  remainder  for  Mission  #2, 
which  are  respectively  the  first  and  second  missions  scheduled  for  the 
first  day  of  operations.  Vehicles  may  either  be  ready  at  zero  time  as 
shown  here,  or  undergoing  unscheduled  maintenance,  by  means  of  Type  #42 
Cards . 

Unit  maintenance  personnel  are  established  with  the  Type  #21  Cards 
shown  in  Fig  11.  Each  forward  operating  unit  has  28  tracked  vehicle 
mechanics,  18  electricians,  16  armament  technicians,  six  recovery 
vehicle  drivers,  and  120  crewmen.  Because  these  units  have  identical 
numbers  of  personnel,  the  #21/88  Type  Card  is  used  to  duplicate  the 
personnel  at  Unit  #1  for  Units  #2  and  #3.  The  FAST  (Unit  #4)  has  16 
tracked  vehicle  mechanics,  ten  electricians,  eight  armament  technicians, 
and  four  recovery  vehicle  drivers.  Support  equipment  stocks  are 
specified  with  #22  Type  Cards.  Three  recovery  vehicles  and  one  A-frame 
are  on  hand  at  each  forward  operating  unit;  as  with  personnel,  support 
equipment  at  Units  #1,  #2,  and  #3  are  identical.  The  FAST  has  two 
recovery  vehicles  and  one  A-frame. 

The  initial  base  stocks  of  spare  parts  may  be  entered  for  each  base 
using  Card  Type  #23,  or  the  user  may  elect  to  take  advantage  of  AURA's 
automatic  parts  initialization  subroutines  by  using  the  special  Type  #23 
Card  formats;  some  of  these  special  features  are  used  in  this  example. 

The  policy  factors  that  govern  (non-battle-damage)  spare  parts 
stocks  to  be  laid  in  at  each  unit  are  entered  with  the  #23/70  and  #23/72 
Type  Cards,  and  the  NRTS  data  and  item  cost  data  for  each  type  of  part 
are  entered  with  the  #23/20x,  #23/30x,  and  #23/66  Card  Types.  Note  that 
advantage  is  taken  of  the  #23/76  Card  Type  to  specify  the  same  NRTS 
rates  at  all  forward  operating  units.  The  DISCOM  provides  a  large 
reserve  of  all  parts  (Type  #23/99  Cards). 

Initial  stocks  of  assembled  and  unassembled  munitions,  accessories, 
POL,  and  building  materials  are  indicated  on  Fig.  12.  As  indicated  with 
the  Type  #29  Cards,  the  same  maintenance  procedures  are  to  be  followed 


SHIPPING  AND  COMMUNICATION 

Only  token  shipments  are  scheduled  (see  Fig.  13)  to  the  theater 
from  CONUS;  6000  rounds  of  Type  #1  Munitions  are  shipped  to  each  forward 
operating  unit  at  noon  on  the  ninth  day  of  the  simulation.  The 
transportation  schedule  between  the  forward  operating  units  and  the  rear 
maintenance  unit  (Card  Type  #32)  specifies  that  shipments  leave  the  FAST 
three  times  daily  to  each  forward  unit,  and  return.  Shipment  times  are 
two  hours  with  no  loss  of  shipments  (Card  Type  #33). 

MISSION  DEMANDS 

Only  one  of  the  several  options  that  are  available  for  specifying 
mission  demands  have  been  used  in  this  sample  data  base.  Each  Type  #50 
Card  shown  in  Fig.  12  calls  for  nine  platoons  of  four  vehicles  to  be 
committed  to  combat  three  times  daily  from  each  battalion-sized  unit. 

The  first  card  calls  for  nine  platoons  from  Unit  #1  to  be  sent  on 
Mission  #1  at  0600.  The  unit  has  a  twelve  hour  notice  of  these  demands, 
and  a  platoon  of  three  vehicles  is  acceptable  if  a  four-vehicle  platoon 
can  not  be  assembled.  These  demands  occur  daily  at  each  of  the  three 
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XXI.  OUTPUTS  FOR  SAMPLE  PROBLEM 


As  explained  in  Section  XV,  AURA  provides  the  user  a  variety  of 
output  options.  This  section  will  illustrate  some  of  those  options  with 
reproductions  of  the  results  for  the  sample  problem  developed  in  the 
preceding  section. 

Figure  13  displays  the  formatted  title  page  that  summarizes  the 
user-selected  values  for  many  of  the  control  variables.  As  noted  at  the 
top,  a  15-day  simulation  is  to  bo  run  for  a  total  of  five  trials.  Three 
task-force  size  units  and  one  FAST  are  involved  in  the  simulation.  A 
variety  of  other  control  variables  are  recorded  in  the  upper  and  center 
sections  of  this  page.  Key  array  dimensions  are  listed  at  the  bottom. 

As  noted  earlier,  the  user  has  two  options  to  control  the  reproduction 
of  input  data.  He  may  specify  that  some,  or  all,  of  the  input  card 
images  be  reproduced  directly,  or  he  may  direct  that  the  input  data  are 
to  be  listed  after  they  have  been  formatted  for  the  storage  arrays.  A 
"l"  in  the  tens  column  of  the  PRINT  variable  means  that  the  initial  Type 
#50  Cards  will  be  displayed. 

Figure  14  illustrates  a  typical  end-of-day  report  for  day  2  of 
Trial  #1.  A  total  of  114  vehicles  remain  at  all  units  with  none  having 
been  lost  in  combat  or  as  a  result  of  enemy  air/artillery  attacks;  none 
have  sustained  battle  damage  during  the  two  days  of  operations.  Of  the 
114  vehicles,  four  are  at  the  FAST,  two  of  which  come  from  Unit  #1  and 
two  from  Unit  #2.  This  can  be  seen  by  examining  the  number  of  vehicles 
cumulatively  withdrawn  to  the  FAST  for  maintenance  by  each  unit  and 
those  cumulatively  returned  to  each  forward  operating  unit. 

At  these  forward  operating  units,  252  vehicles  were  committed  to 
combat  (i.e.,  sent  on  missions)  during  the  second  day.  The  number  of 
platoons  committed  to  combat  and  the  number  demanded  (nine  per  task 
force  for  each  of  the  three  missions  that  day)  are  shown  next.  The 
first  four  columns  refer  to  Unit  #1,  the  next  four  to  Unit  #2,  and  so 
on.  The  FAST  naturally,  does  not  commit  vehicles  to  combat. 

The  number  of  vehicles  committed  to  combat  by  unit  and  mission  type 
follows,  along  with  the  number  demanded  and  the  ratio  of  committed  to 
demanded.  Usually  the  number  of  vehicles  committed  equals  the  number  of 
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platoons  times  platoon  size  except  when  the  user  permits  understrength 
platoons  to  be  committed  by  a  unit,  e.g.,  three  vehicles  instead  of  the 
normal  four. 

The  rates  at  which  vehicles  have  been  made  ready  for  another  combat 
mission  are  indicated  for  each  forward  operating  unit.  At  Unit  #1,  for 
example,  27  percent  of  the  vehicles  were  reconstituted  within  two  hours 
and  76  percent  within  four  hours  of  the  time  they  arrived  at  the  task 
force  bivouac  area  from  their  last  mission.  The  hourly  record  of 
mission  generation,  i.e.,  vehicles  committed  to  combat  on  a  given 
mission,  is  shown  next.  These  data  are  sometimes  useful  in  determining 
how  many  vehicles  had  late  "jump  off"  times. 

The  shop  status  reports  shown  next  include  not  only  the  current 
activity  but  also  the  totals  of  the  on-vehicle,  off-vehicle,  and  support 
equipment  repair  jobs  that  were  completed  during  the  preceding  24  hours, 
and  the  cumulative  numbers  of  manhours  expended  in  each  shop.  The 
number  in  parentheses  at  the  right  end  of  the  on-vehicle  task  line  is 
the  cumulative  number  of  parts  cannibalization  actions;  in  this  case 
lone  occurred  at  Unit  0 1 .  The  two  numbers  in  parentheses  at  the  right 
end  of  the  off-vehicle  line  are,  first,  the  cumulative  number  of  LRUs 
that  have  been  cannibalized  to  obtain  an  SRU,  and  second,  the  cumulative 
number  of  repairs  that  have  been  expedited;  in  this  case,  none  again. 

On-vehicle  tasks  currently  being  performed,  as  well  as  those 
waiting  and  interrupted,  are  indicated  next.  Parts  repair  (not 
considered  in  this  sample  problem)  on-going,  waiting,  and  interrupted 
are  also  displayed.  A  negative  entry  for  on-going  repairs  is  actually  a 
record  of  the  damage  level  at  that  shop  from  enemy  air/artillery 
attacks;  the  minus  sign  signals  that  this  is  the  appropriate 
interpretation.  Identical  information  is  provided  for  all  the  remaining 
units  including  the  FAST,  if  included  in  the  simulation. 

Figure  15  illustrates  a  typical  end-of-trial  report.  Platoons  and 
vehicles  committed  to  combat  over  the  entire  period  of  operations  are 
shown  along  with  the  cumulative  demands.  Cumulative  number  of 
on-vehicle  and  off-vehicle  tasks  by  shop  and  unit  are  also  displayed. 

More  accurate  and  specific  indications  of  resource  constraints  are 
provided  by  the  data  listed  in  Fig.  16.  This  figure  summarizes  the 
cause  and  the  extent  of  all  vehicle  maintenance  and  supply  delays.  Each 
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type  of  maintenance  personnel,  support  equipment,  etc.  for  which  a 
shortage  caused  an  on-vehicle  task  to  be  delayed  is  recorded.  These 
statistics  provide  an  excellent  indication  of  the  bottlenecks  and 
obvious  indications  of  where  extra  resources  could  be  of  help  in 
improving  each  unit's  mission-generation  capabilities.  In  this  instance 
there  were  delays  for  recovery  vehicle  drivers  and  crewmen  at  Unit  #1 
that  averaged  3  hours  and  0.8  hours,  respectively.  A  greater  number  of 
these  MOSs  clearly  would  have  reduced  the  backlog  of  work. 

The  status  of  spares  at  each  unit  is  also  available;  the  number  of 
in-unit  serviceables  and  reparables  are  listed  for  each  part  type.  The 
total  number  of  spares  that  were  removed  from  vehicles  during  the 
simulation  is  also  shown  for  each  unit. 

Figure  17  illustrates  the  summary  data  provided  at  the  completion 
of  the  specified  number  of  trials.  Data  include  the  average  number  of 
vehicles  committed  to  combat  each  day  at  all  operating  units,  as  well  as 
the  average  number  of  vehicles  committed  of  each  mission  type  at  each 
unit;  the  standard  deviation  is  also  listed  in  the  latter  case.  As 
before,  the  first  four  columns  refer  to  Unit  #1,  and  so  on.  The  output 
is  concluded  with  records  of  the  average  number  of  vehicles  committed  to 
combat  throughout  the  simulation  for  each  mission  type  and  each  unit,  as 
well  as  at  all  units.  These  data  are  useful  in  calculating  the 
readiness  and  sustainability  indexes  described  in  R-2769-MRAL  (see 
Preface) . 
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XXII.  CHECKING  FOR  DATA  SET  CONSISTENCY 


AURA  was  designed  to  enable  the  user  to  pose  a  large  number  of 
"what  if"  questions.  Many  of  these  can  be  handled  by  making  one  or  a 
few  seemingly  simple  changes  in  the  input  data,  but  because  AURA  is  a 
complex  model,  the  user  should  exercise  care  when  making  such  changes  in 
proven  data  sets.  To  maintain  the  necessary  internal  consistency  of  a 
data  set  when  new  simulation  conditions  are  desired,  the  user  must  check 
carefully  to  ensure  that  the  impact  of  a  change  in  one  part  of  the  data 
set  is  adequately  reflected  in  other  parts  that  interact  with  it.  Such 
inconsistencies  are  particularly  likely  when  the  user  attempts  to  use  a 
data  set  that  has  been  derived  (i.e.,  patched  together)  from  a 
collection  of  previously  successful  input  data  sets.  To  help  avoid  some 
of  these  problems,  this  section  gives  a  few  examples  of  links  between 
card  types  that  should  be  noted  when  making  changes.  These  examples  are 
not  a  complete  list. 

CROSS  TRAINING 

The  use  of  this  option  would  allow  a  particular  type  of  maintenance 
personnel  to  perform  work  normally  associated  with  a  different  type  of 
person  or  to  assist  in  the  performance  of  that  task.  A  "l"  must  be 
placed  in  column  25  of  the  Type  .'*17  Card  to  indicate  the  unit  has  cross- 
trained  personnel.  The  tasks  must  be  identified  by  placing  a  "l"  in 
column  79  of  the  Type  # 5  Cards,  in  columns  30,  55,  and  80  of  the  Type 
#11  Cards,  and  in  columns  15  and  35  of  the  Type  #13  Cards  on  which  the 
particular  task  appears.  The  personnel  types  so  cross-trained  must  be 
identified  on  a  Type  #4 5/2  Card  if  they  can  replace  the  original  type, 
or  on  a  #45/3  Card  if  they  can  assist  the  original  type.  Caution  should 
be  exercised  in  the  interpretation  of  the  output  when  this  option  is 
used  as  delay  times  will  be  accrued  to  the  "home"  shop  of  the  cross- 
trained  individual,  should  work  be  waiting  there,  even  if  he  is  active 
in  his  secondary  capacity.  The  time  spent  in  working  at  a  shop, 
however,  is  logged  against  that  shop  without  indicating  that  the  work 
was  done  by  a  visitor. 
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PARTS  REPAIR 

The  user  may  wish  to  see  the  effect  of  changing  the  condemnation 
rate,  the  NRTS  rate,  or  the  probability  of  some  repair  alternative.  For 
each  part,  unless  a  Card  Type  #5  entry  shows  in  columns  68-70  that  it  is 
always  condemned,  or  a  Card  Type  .723  shows  it  is  never  repaired  anywhere 
in  the  simulation,  i.e.,  a  100  percent  NRTS  rate  at  every  unit,  the  user 
must  provide  repair  information  on  the  Type  # 8  Card  and  routing 
information  on  the  Type  #34  Card.  A  part  that  is  "\RSTed"  to  another 
unit,  e.g.,  a  FAST  or  DISCOM,  will  be  sent  to  the  lowest  echelon  of 
maintenance  at  which  the  NRTS  rate  is  less  than  100  percent;  the  part 
will  bypass  any  echelon  of  maintenance  that  is  unable  to  effect  the 
repair,  regardless  of  the  routing  data  on  the  Type  #34  Card.  The  user 
should  also  check  that  if  the.  repair  of  a  part  is  permitted  at  a  unit 
not  previously  assigned  that  task,  the  resources  required  for  that  job 
are  recognized  on  the  Type  #21,  #22,  and  #23  Cards.1 

When  changing  task  probabilities,  the  user  must  ensure  that  the  sum 
of  probabilities  of  a  set  of  mutually  exclusive  tasks  is  unity.  This 
applies  to  repair  alternatives  on  the  Type  #8  Card  as  well  as  networks 
on  the  Type  #5  Card,  whose  task  probabilities  are  preceded  by  a  minus 
sign  in  columns  36-39. 

VEHICLE  NUMBERS,  CONFIGURATIONS,  AND  MISSIONS 

The  user  may  wish  to  make  a  number  of  changes  regarding  the  number 
of  vehicles  at  a  unit,  or  the  number  of  vehicles  to  be  commit ■ ed  to 
combat  at  a  certain  time.  Because  AURA  keeps  track  of  vehicles 
individually,  information  on  vehicles  must  not  conflict  from  one  card 
type  to  another.  For  example,  if  a  unit  has  54  tanks  of  a  given  type, 
as  shown  on  the  Type  #20  Card,  then  the  sum  of  tanks  in  various  initial 
configurations  on  the  Type  #41  Card  must  also  be  54.  Changing  the 

1  If  the  personnel  type  for  a  particular  task  is  not  present  at  a 
unit,  the  AURA's  data  editor  will  upon  initialization  uncover  that  fact 
and  stop  the  the  simulation  with  an  appropriate  message.  However, 
missing  support  equipment  will  not  be  flagged  by  the  current  AURA 
software.  Further,  t*  ■*  user  mist  also  check  that  repair  team  sizes 
indicated  on  the  Type  ,h>  Card  do  not  exceed  the  maximal  shift 
assignments,  as  this  will  not  stop  the  simulation  either.  The  user  will 
first  discover  these  "missing  resources"  by  observing  that  these  jobs 
fail  to  process  through  otherwise  "idle"  shops. 
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number  of  vehicles  at  a  unit  requires  changing  the  initial  configuration 
mix  as  well.  Changing  the  number  of  vehicles  to  be  committed  to  combat 
on  the  Type  #50  Cards  without  changing  the  initial  configuration  mix  may 
also  lead  to  anomalies  as  the  unit  may  be  unable  to  respond  fully  early 
in  the  simulated  period  of  operations. 

SHIFTING  UNIT  POSTURE 

Perhaps  the  most  complex  of  the  more  common  data  set  changes  occurs 
when  the  user  wishes  to  shift  a  large  set  of  units  from  a  series  of 
defensive  operations  to  a  series  of  offensive  operations  or  vice  versa. 
Changes  to  the  Type  #*'50  Cards  are  probably  the  most  self-evident,  but 
several  other  curd  types  may  bo  affected  as  a  consequence.  If  attrition 
parameters  are  different,  as  is  likely,  then  several  entries  on  the  Type 
#16  Card  must  be  changed,  as  well  as  those  Type  #5  Card  entries  that 
treat  battle  damage.  Any  difference  in  mission  duration  requires  a 
change  in  the  Type  •••■In  Card,  and  possibly  in  the  task  probability 
modifiers  cm  the  Type  «44  Card,  should  mission  mileage  and/or  firing 
rates  change.  If  mission  mileage  does  in  fact  change,  then  it  is  likely 
that  the  user  would  want  to  modify  the  refuel  quantity  in  columns  21-25 
of  the  Type  #15/1  Card.  If  firing  rates  change,  then  the  user  must 
change  the  primary  munition  quantity  in  columns  19/20  of  the  Type  #13 
Card  and  the  secondary  munitions  quantities,  if  appropriate,  also  on  the 
Type  #15/1  Card. 

Card  Type  #41  should  now  show  the  number  of  vehicles  configured  for 
the  new  first  mission,  which  is  on  the  revised  Type  #50  Cards.  Should 
resupply  rates  be  different  due  to  changes  in  consumption,  LOC 
distances,  or  logistic  sources,  the  user  must  reflect  these  in  Card 
Types  #31  and  #43.  Personnel  and  support  equipment  realignments  should 
be  reflected  in  Card  Types  #21  and  #22  respectively.  Should  the  FAST  or 
DISCOM  be  required  to  move  on  a  different  schedule,  changes  are  required 
in  Type  #40  Card  for  the  "shutdown"  time,  and  to  the  SHPDLY  parameter  on 
the  Type  #4/1  Card,  if  the  time  spent  moving  differs. 

The  changes  mentioned  in  this  subsection  are  not  meant  to  be 
exhaustive,  but  only  to  relect  recent  experience.  The  user  may  well 
identify  other  changes  to  the  input  data  set  that  are  necessary  to 
perform  his  desired  simulation. 


